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(54) Mobile-telephone system call processing arrangement 



(57) A CDMA cellular radio-telephone system 
comprises a packet-switched communications 
network (202, 207, 201) that interconnects cells 
(base stations ; 202) with each other and with 
the public telephone network (100). A unique 
combination of a static addressing plan that 
uses a different LAPD DLCI for each unidirec- 
tional virtual call path, direct cell (202)-to-cell 
and cell-to-call-processing unit control infor- 
mation exchanges, and packet-switching 
techniques that permit call traffic and control 
communications to share call paths and permit 
different call paths to share physical resources, 
is applied to call processing. This enables soft 
handoffs to be handled in a manner transparent 
to the parties to the call and without significant 
involvement of system control elements (134 
and 261) whose involvement would adversely 
impact the system's call-handling capacity. It 
also enables soft handoffs to occur without 
change of the call processing unit that is hand- 
ling the call, so that a single call processing unit 
continues to handle the call from start to finish 
through even multiple soft handoffs. 
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Technical Field 

This invention relates to call processing arrange- 
ments of wireless-access, and particularly of cellular 
radio-telephone, communications systems. 

Background of the Invention 

Wireless-access telecommunications systems 
are well known in the art They provide over-the-air 
(e.g., radio wave, infrared) connections between user 
communication terminals and a communications 
switching and transport network such as the tele- 
phone network. An illustrative example thereof are 
cellular radio-telephone systems. 

In cellular radio-telephone systems, a plurality of 
radio cells, also referred to as base stations, are dis- 
persed through a geographical area and each pro- 
vides radio-telephone service to radio-telephones in 
its vicinity, referred to as a cell zone. The cells are 
conventionally connected to the public telephone net- 
work through a circuit-switched communications net- 
work known in the art collectively as a Mobile Tele- 
phone Switching Office (MTSO) or Mobile Switching 
Center (MSC). When a mobile radio-telephone 
crosses from one cell zone to another, its servicing is 
transferred from the cell serving the one cell zone to 
the cell serving the other cell zone through a process 
known as a "hard handoff* . Adjacent cell sites operate 
at different radio frequencies, so a "hard handoff in- 
volves a change in the radio frequency that is used to 
service the mobile telephone. This change in turn re- 
quires the cellular radio- telephone system to make a 
second communications connection to the mobile ra- 
dio-telephone and to simultaneously drop the first 
connection. This takes time and uses processing ca- 
pacity and switching fabric resources, thereby having 
a negative impact on the system's call-carrying ca- 
pacity. 

Mobile telephony is very popular, and the number 
of mobile radio-telephones is growing. This results in 
congestion of the presently-allocated radio-frequency 
spectrum and a need to more efficiently use that ra- 
dio-frequency spectrum. The conventional mobile ra- 
dio-telephony technique, known as frequency-divi- 
sion multiple-access (FDMA), tries to maximize ca- 
pacity by splitting available bandwidth into separate 
channels in the frequency domain (e.g., into 30 KHz 
channels). But the radio-frequency spectrum that is 
allocated to mobile radio-telephone service is limited 
to 60 MHz. 

A capacity-expanding technique, known as time- 
division multiple-access (TDMA) is known in the art 
and is a subject of technical standardization. It is a 
digital radio technique that splits each 30 KHz channel 
frequency into a plurality of time slots, each one or 
more of which' can then act as a separate channel. 
The handoff procedure is similar to that used for con- 
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ventional mobile radio-telephony, so the TDMA tech- 
nique can in many instances be handled through con- 
ventionally-structured radio-telephone systems with 
only a change-out of the radio, i.e., the radio-frequen- 

5 cy transmission and reception, equipment. But it only 
increases total system capacity approximately three- 
fold in mobile applications, which may not be ade- 
quate in many congested areas where cellular com- 
munications traffic is very high. 

10 An alternative capacity-expanding technique, 

known as code-division multiple-access (CDMA) has 
been proposed. It is a dynamic transmission- power 
control and digital direct-sequence spread-spectrum 
technique that allows reuse of the same radio-fre- 
ts quency spectrum in adjacent cells. It yields up to ap- 
proximately a twenty-fold increase in capacity over 
conventional FDMA systems. Mobile telephones in a 
CDMA cellular radio-telephone system may undergo 
"hard handofr between cells. But, due to the frequen- 

20 cy reuse between adjacent cells, a mobile radio-tele- 
phone that is crossing from one cell zone to another 
may sometimes find itself communicating with two 
cells on the same radio-channel at the same time, a 
situation known as "soft handoff*. A whole sequence 

25 of "soft handoffs" may occur as a mobile radio-tele- 
phone moves through a series of cells. 

Handling of CDMA call capacity and "soft hand- 
ofr is not easily accomplished in a conventional mo- 
bile radio-telephone system having the conventional 

30 FDMA architecture. This is due in large measure to the 
fact that there are typically many more "soft hand of fs" 
in a typical CDMA system than there are "hard hand- 
offs" in a conventional system and the "soft handoffs" 
are typically of longer duration than "hard handoffs", 

35 and so the demands placed by "soft handoffs" on sys- 
tem resources and processing and switching facilities 
are more extensive and acute. Handling of "soft hand- 
ofr additionally requires, inter alia: routing of the du- 
plicate communications received from one mobile tel- 

40 ephone at the two cells to a common call-processing 
point in the system, for selection in real time of one 
and discarding of the other duplicate communication; 
duplication of return communications and routing 
thereof to the two cells; and coordinatidn of the oper- 

45 ations of the two cells so that they transit the duplicate 
return communications to the mobile telephone at the 
same time. Conceivable ways of meeting these re- 
quirements in conventionally-architected radio-tele- 
phone systems appear to be awkward, inefficient, 

so complex, and expensive. 

Furthermore, since each radio at a cell typically 
requires a unique trunk connection to the telephone 
network, handing off of a call from one radio to an- 
other radio requires the mobile-telephone switching 

55 fabric to be reconf igured to connect the new radio and 
trunk to the original network trunk connection. In con- 
ventional systems, the total system capacity is a func- 
tion of the amount of initial radio-to-network trunk 

2 
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connections the system can handle and the amount 
of reconfiguration (i.e. handoff) the system must per- 
form. The reconfiguration requires intervention of the 
system control structures, and the length of time re- 
quired for reconfiguring these trunks increases the 5 
complexity of these system control structures. CDMA 
systems require establishment of a second radio con- 
nection for "soft handoff at rates faster than those 
needed for traditional handoffs, thereby taxing or ex- 
ceeding the processing and reconfiguration capabili- 10 
ties of systems of conventional design. 

Summary of the Invention 

This invention is directed to solving these and 15 
other problems and disadvantages of the prior art. 
Briefly according to the invention, a unique combina- 
tion of a static addressing plan, direct cell-to-cell and 
cell-to-call-processing unit control information ex- 
changes, and the application of packet-switching 20 
techniques enable certain call handoffs, particularly 
soft handoTs, to be handled in a manner that does not 
adversely impact a wireless-access system's call- 
handling capacity. Specifically, soft handoffs are per- 
formed in a manner transparent to the parties to the 25 
call, through a simple control procedure that does not 
require involvement therein of system control ele- 
ments such as a system controller that otherwise co- 
ordinates the operations of wireless-call service 
nodes (e.g. cells) and interface nodes (e.g. switches) 30 
or interface node controllers that otherwise are re- 
sponsible for connecting call processing units of the 
interface nodes to calls and whose involvement would 
adversely impact the systems call-handling capacity, 
and without change in the call processing unit that is 35 
handling the call so that a single call processing unit 
continues to handle a call from start to finish even 
through numerous soft handoffs. Additionally, the use 
of a static addressing plan reduces the amount of 
processing required for the set-up and tear-down of 40 
call paths, while the use of packet-switching techni- 
ques —illustratively such as frame-relay for transport- 
ing both traffic and control communications and the 
use of a virtual circuit for the setting up of call paths- 
- eliminates the use of additional switching fabric and 45 
transport facilities (e.g., trunks) for the handling of 
soft handoffs. 

The invention pertains to a wireless- access tel- 
ecommunications system that includes at least one 
mobile wireless-call user terminal, a plurality of ser- 50 
vice nodes each for providing wireless-call services to 
wireless-call user terminals in its vicinity, and at least 
one interface node connected to the service nodes 
and having a plurality of call processing units each for 
interfacing a wireless call that extends between a 55 
user terminal and a service node to a telecommuni- 
cations facility. This may be, for example a CDMA cel- 
lular radio-telephone system that includes mobile ra- 



dio-telephones, cells (or cell sectors) each one of 
which serves a particular service zone, and a cellular 
switching system that includes speech processing 
unit service circuits each for processing a single call 
at any one time and interfacing the call's traffic with 
a telephony trunk. According to the invention, in such 
a system, the call of a mobile user terminal that is 
moving from a vicinity of a first service node to the vi- 
cinity of a second service node (i.e., is in a handoff 
condition) is handled as follows. While the mobile user 
terminal is still in the vicinity of the first service node, 
call traffic of the call is communicated between the 
mobile user terminal and the first service node, and 
between one of the call processing units and a tele- 
communications facility, as is usual. But, between the 
first service node and the one call processing unit, the 
call traffic is communicated across a packet-switched 
call path set up for the call on a communication chan- 
nel between the first service node and the one call 
processing unit, using different fixed addresses for 
different endpoints of the call path to route the call 
traffic across the channel. Then, in response to a de- 
tection that the mobile user terminal is moving from 
the vicinity of the first service node to the vicinity of 
the second service node, notification thereof is sent 
from the first service node to the second service 
node. In response to receipt of the notification at the 
second service node, a packet-switched call path for 
the call is set up on a communication channel be- 
tween the second service node and the one call proc- 
essing unit by communicating across the communica- 
tion channel between the second service node and 
the one call processing unit. Thereafter, duplicate call 
traffic of the call is communicated between both the 
first and the second service nodes and the one call 
processing unit, across the packet-switched call 
paths set up for the call on the communication chan- 
nels between the first and the second service nodes 
and the one call processing unit, using different fixed 
addresses for different endpoints of every call path to 
route the duplicate call traffic across the channels. 
That duplicate call traffic is also communicated be- 
tween the mobile user terminal and both the first and 
the second service nodes. But at the one call process- 
ing unit which alone continues to serve the call, only 
a single copy of the duplicate call traffic of the call is 
communicated between the one call processing unit 
and the telecommunications facility, by duplicating the 
single copy of the call traffic outgoing to the service 
nodes and discarding a duplicate of the call traffic in- 
coming from the service nodes. 

While the discussion of an illustrative embodi- 
ment that follows makes a distinction between level- 
3 "packets" and level-2 "frames' 1 , for purposes of clar- 
ity, the use of the term "packet herein and in the claims 
is intended to encompass either or both "pack- 
ets" and "frames". 

According to an illustrative embodiment of the in- 
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vention, the call of the mobile wireless-call user ter- 
minal that is moving from the vicinity of the first ser- 
vice node to the vicinity of the second service node is 
handled as follows. In response to receiving incoming 
call traffic of the call from the mobile user terminal at 5 
the first service node, first packets containing the re- 
ceived incoming call traffic and each having a first ad- 
dress which identifies the call's corresponding one of 
the call processing units are sent from the first service 
node to the interface node. In response to receiving 10 
the first packets at the one call processing unit, the in- 
coming call traffic contained in the first packets is sent 
from the one call processing unit to a telecommunica- 
tions facility. In response to receiving outgoing call 
traffic of the call from the telecommunications facility 15 
at the one call processing unit, second packets con- 
taining the received outgoing call traffic and each 
having a second address different from the first ad- 
dress and which identifies the first service node are 
sent from the one call processing unit to the first ser- 20 
vice node. In response to receiving the second pack- 
ets at the first service node, the outgoing call traffic 
contained in the second packets is sent from the first 
service node to the mobile user terminal. When de- 
tection is made that the mobile user terminal is mov- 25 
ing from the vicinity of the first service node to the vi- 
cinity of the second service node, a message speci- 
fying a third address different from the first address 
and which also identifies the one call processing unit 
is sent from the first service node to the second ser- 30 
vice node. In response to receiving the message at 
the second service node, a third packet both (a) spec- 
ifying a fourth address different from the second and 
the third addresses and which identifies the second 
service node and (b) having the third address, is sent 35 
from the second service node to the interface node. 
Then, in response to receiving incoming call traffic of 
the call from the mobile user terminal at the second 
service node subsequently to receiving the message, 
fourth packets containing the received incoming call 40 
traffic and each having the third address are sent from 
the second service node to the interface node, ana- 
logously to what is also being done with the traffic at 
the first service node. In response to receiving the 
third packet at the one call processing unit, the fourth 45 
address is stored for use in the call by the one call 
processing unit. Thereafter, in response to receiving 
outgoing call traffic of the call from the telecommuni- 
cations facility subsequently to receiving the third 
packet, second packets continue to be sent from the so 
one call processing unit to the first service node, but 
also fifth packets containing the same received out- 
going call traffic as the second packets and each hav- 
ing the fourth address are now sent from the one call 
processing unit to the second service node. In re- 55 
sponse to receiving the fifth packets at the second 
service node, the outgoing call traffic contained in the 
fifth packets is sent from the second service node to 



the mobile user terminal, analogously to what is also 
being done with the traffic at the first service node. 
And, in response to receiving the first packets and the 
fourth packets both containing the same received in- 
coming call traffic at the one call processing unit sub- 
sequently to receiving the third packet, the incoming 
call traffic contained by only one of the received first 
and fourth packets that contain the same traffic is se- 
lected and only the selected incoming call traffic is 
sent to the telecommunications facility. 

The abovementioned, as well as other, features 
and advantages of the invention will become apparent 
from the following description of an illustrative em- 
bodiment of the invention considered together with 
the drawing. 

Brief Description of the Drawing 

FIG. 1 is a block diagram of a conventional cellu- 
lar radio-telephone system; 
FIG. 2 is a block diagram of a cellular radio-tele- 
phone system that incorporates an illustrative 
embodiment of the invention; 
FIG. 3 is a block diagram of a cell of the system 
of FIG. 2; 

FIG. 4 is a block diagram of a cell interconnect 
module of the system of FIG. 2; 
FIG. 5 is a block diagram of a speech coding mod- 
ule of the system of FIG. 2; 
FIG. 6 is a block diagram of a speech processing 
unit of the module of FIG. 5; 
FIG. 7 is a block diagram of a LAPD frame of the 
system of FIG. 2; 

FIG. 8 is a block diagram of a modified LAPD 
frame of the system of FIG. 2; 
FIG. 9 is a block diagram of a level-3 protocol 
used for carrying voice and/or signalling informa- 
tion in the frames of FIGS. 7 and 8; 
FIG. 10 is a block diagram of a level-3 protocol 
used for carrying signalling information in the 
frames of FIGS. 7 and 8; 
FIGS. 11-14 are a flow diagram of received-pack- 
et processing functions of the processor of the 
unit of FIG. 6; 

FIG. 15 is a flow diagram of transmit- packet proc- 
essing functions of the processor of the unit of 
FIG. 6; 

FIG. 16 is a flow diagram of clock adjustment 
functions of a cluster controller of the cell of FIG. 

3; 

FIG. 17 is a flow diagram of clock adjustment 
functions of the processor of the unit of FIG. 6 
performed at step 970 of FIG. 11; 
FIG. 18 is a flow diagram of clock adjustment 
functions of the processor of the unit of FIG. 6 
performed at step 912 of FIG. 11; 
FIG. 19 is a timing diagram of packet-transmis- 
sion clock-adjustments performed at call setup 
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for a service circuit of the unit of FIG. 6; 
FIG. 20 is a timing diagram of packet-reception 
clock-adjustments performed at call setup for a 
service circuit of the unit of FIG. 6; 
FIG. 21 is a timing diagram of packet-transmis- 5 
sion clock-adjustments performed during an es- 
tablished call for a service circuit of the unit of 
FIG. 6; 

FIG. 22 is a timing diagram of packet-reception 
clock-adjustments performed during an estab- 10 
lished call for a service circuit of the unit of FIG. 
6; 

FIG. 23 is a signalling diagram of setup of a mo- 
bile-originated call in the system of FIG. 2; 
FIG. 24 is a signalling diagram of setup of a net- 15 
work-originated call in the system of FIG. 2; 
FIG. 25 is a signalling diagram of a mobile-origin- 
ated disconnection of a call in the system of FIG. 
2; 

FIG. 26 is a signalling diagram of a network-ori- 20 
ginated disconnection of a call in the system of 
FIG. 2; 

FIG. 27 is a signalling diagram of the beginning of 
a soft-handoff of a call in the system of FIG. 2; 
FIG. 28 is a signalling diagram of the end of a soft- 25 
handoff wherein a master cell drops off; 
FIG. 29 is a signalling diagram of the end of a soft- 
handoff wherein a slave cell drops off; 
FIG. 30 is a signalling diagram of a mobile-origin- 
ated disconnection of a call during soft-handoff in 30 
the system of FIG. 2; 

FIG. 31 is a signalling diagram of a network-ori- 
ginated disconnection of a call during soft- 
handoff in the system of FIG. 2; 
FIG. 32 is a signalling diagram of a semi-soft- 35 
handoff of a call in the system of FIG. 2; 
FIG. 33 is a signalling diagram of a CDMA-to- 
CDMAhard-handoff of a call in the system of FIG. 
2; 

FIG. 34 is a signalling diagram of a CDMA-to- 40 
analog hard-handoff of a call between cells 
served by the same digital cellular switch in the 
system of FIG. 2; and 

FIG. 35 is a signalling diagram of a CDMA-to- 
analog hard-handoff of a call between cells 45 
served by different digital cellular switches in the 
system of FIG. 2. 
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Before commencing a discussion of an illustrative 
implementation of the invention, it may be helpful to 
consider an existing cellular mobile radio-telephone 
system to serve as a basis for comparison. Such a 
system is shown in FIG. 1 . Adescription of such a sys- 55 
tern may be found in K. W. Strom, "On the Road with 
AUTOPLEX System 1 000", AT&T Technology , Vol. 3, 
No. 3, 1988, pp. 42-51, and W. J. Hardy and R. A. 



Lemp, "New AUTOPLEX Cell Site Paves The Way For 
Digital Cellular Communications", AT&T Technology , 
Vol. 5, No. 4, 1990, pp. 20-25. 

The system of FIG. 1 includes a plurality of geo- 
graphically-dispersed service nodes known as cell 
sites, or cells 102 for short, each one of which pro- 
vides radio-telephone services to wireless user termi- 
nals, known as mobile radiotelephones 103, in its vi- 
cinity. To provide radio-telephone service between 
mobile radio-telephones 103 served by different cells 
102, and between mobile radio-telephones 103 and 
the public telephone network 100, cells 102 are inter- 
faced to each other and to network 100 through mo- 
bile radio-telephone switching nodes referred to here- 
in as digital cellular switches (DCSs) 101. Each switch 
101 is illustratively the AT&T Autoplex® cellular tele- 
communications system digital cellular switch. Each 
digital cellular switch 101 is connected to a plurality of 
different cells 102 by communication trunks 107, and 
is connected to network 100 by communication 
trunks 106. Each trunk 106 and 107 is illustratively a 
DS0 (64 Kbps time-division multiplexed) channel, a 
plurality of which are implemented by a DS1 facility 
which may be transported via land line (T1 line), opt- 
ical transmission, microwave, etc., facilities. Control 
over the system of FIG, 1 and coordination of the ac- 
tivities of the vinous ceils 102 and DCSs 101 is exer- 
cised by an Executive Cellular Processor (ECP) 105, 
which is connected to each cell 102 and cellular 
switch 101 through an Interprocess-Message Switch 
(IMS) 104 by control links 108. ECP 105 and IMS 
1000 together make up an ECP complex 134. ECP 
complex 134 and DCS 101 make up a mobile switch- 
ing center (MSC) 199. ECP 105 and IMS 104 are il- 
lustratively the AT&T Autoplex ECP and the AT&T Au- 
toplex IMS (which includes a plurality of cell site node 
processors, digital switch node processors, and data- 
base node processors, interconnected by an IMS 
ring), and links 108 are illustratively RS-449 data links 
within MSC 199. Alternatively, control links 108 may 
be implemented as 64 Kbps DS0 channels on DS1 fa- 
cilities between cells 102 and mobile switching center 
199. 

Each mobile radio-telephone 103 typically com- 
prises an analog FM radio-telephone capable of op- 
erating at any one of a plurality of radio frequency 
pairs. Each cell 102 comprises a plurality of analog 
FM radios 143 each operating at one of the radio fire- . 
quency pairs of the mobile radio-telephones 103. Ra- 
dios 143 of adjacent cells 102 operate at different fre- 
quency pairs, to avoid interfering with each other. 
However, each mobile radio-telephone 103 is typical- 
ly capable of operating at any of the frequency pairs 
of all of the cells 102. 

In an alternative embodiment, digital radios and 
radio-telephones operating in the-division multiple- 
access (TDM A) mode are substituted for the analog 
FM radios and radio-telephones. Vocoding functions 
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can be a part of the radio units in this embodiment, or 
can be located at switches 101. 

While in a cellular system, a mobile radio-tele- 
phone's receiver scans a set of predetermined paging 
channels. After locking onto the strongest paging 
channel, the mobile radio-telephone 1 03 gets instruc- 
tions from the system and receives incoming calls. A 
mobile radio-telephone 103 also transmits on a chan- 
nel to originate a call. When a call is established (in- 
coming or outgoing) the receiver is assigned to a par- 
ticular voice channel and instructed to tune to that 
transmit and receive frequency pair. At the same time, 
a connection is established between the cell 102 and 
the telephone network 100 through a digital cellular 
switch 1 01 , which completes the voice path for the tel- 
ephone conversation. 

Once this voice connection is established, the ra- 
dio signal levels are monitored by the cell's radio 143. 
As the mobile radio-telephone 103 moves from one 
cell into another, the serving cell 1 02 detects the re- 
duction in signal strength and requests that measure- 
ments be made by surrounding cells 102. If these 
measurements indicate that another cell 102 can pro- 
vide better service, then the voice connection is 
switched to that cell 102 through a process known as 
"hard handoff. The process of hard handoff is under 
control of ECP 105 and requires that a DCS 101 first 
fonn a 3-way connection which extends the voice cir- 
cuit from the serving trunk 106 to radio channels in 
both the serving cell 102 and the target cell 102. 
When this connection has been confirmed, the radio- 
telephone 103 is instructed to retune to the frequency 
of the assigned radio 143 in the target cell 102. Upon 
confirmation of the radio-telephone's communication 
with the target cell 102, the DCS 101 is then instructed 
to remove the voice connection to the original serving 
cell 102, leaving the connection between the new 
serving (target) cell 102 and the serving trunk 106. 
The telephone conversation continues largely unin- 
terrupted through this handoff process. Meanwhile, 
the original voice channel is made available for use by 
another subscriber. 

Hard handoffs performed in this way use proces- 
sor capacity in both the ECP complex 1 34 and the dig- 
ital cellular switch 101. For the duration of the 3-way 
connection, the hard handoff also uses additional 
switch fabric CTDM bus 1 30) capacity. If the target cell 
1 02 containing the selected radio 143 is connected to 
a switching module 120 other than the oue containing 
the serving trunk 106, then the connection must be 
extended through a time-multiplexed switch (TMS) 
121, using additional switching fabric in that switch 
element. As the numberof cells 102 in a system grows 
larger, the number of handoffs increases and uses an 
increasing proportion of the system processor and 
switch fabric resources, thus reducing the system's 
overall capacity. 

Each cell 102 is configured around a high-speed 



time-division mulriplexed (TDM) bus 140. TDM bus 
140 is illustratively the 2.048 MHz TDM bus of an 
AT&T Definity® communications system Universal 
Module, and physically comprises one or more TDM 

5 buses each having 256 time-slots per frame. Illustra- 
tively, multiple TDM buses are used simultaneously 
by units connected thereto and logically operate as a 
single TDM bus having a multiple of 256 time slots per 
frame. Each the slot has a rate of 64 Kbps. Within a 

10 celt 102, radios 143 are connected to TDM bus 140. 
Radios 143 accept communications for radio trans- 
mission from, and supply received radio communica- 
tions to, TDM bus 140 in DS0 channel format at a rate 
of 64 Kbps. The input to, and output from, each radio 

15 is full-rate pulse-code-modulation (PCM)-coded 
speech. Also connected to TDM bus 140 are one or 
more interfaces 142, each one of which couples TDM 
bus 140 to trunks 107. Illustratively, trunks 107 are 
carried by T1 facilities employing the DS1 communi- 

20 cation format and operating at a rate of 1 .544 Mbps, 
and so interfaces 142 are DS1 interfaces. The DS1 
and the aforementioned DS0 format are described by 
T. H. Murray in 'The Evolution of DDS Networks: Part 
1", Telecommunications , February 1989, pp. 39-47. 

25 An interface 142 accepts from TDM bus 140 commu- 
nications that have been supplied by a plurality of ra- 
dios 143, multiplexes them into the DS1 format, and 
transmits them onto trunks 107. In the reverse direc- 
tion, interface 142 receives from trunks 107 commu- 

30 nications formatted in the DS1 format, demultiplexes 
them, and supplies them to TDM bus 140 for convey- 
ance to radios 143. TDM bus 140 operates under con- 
trol of a controller 141, which allocates time slots on 
bus 140 to individual ones of the radios 143 and in- 

35 terfaces 142. Illustratively, controller 141 makes 
these allocations on the basis of control information 
supplied thereto by ECP complex 134 over a control 
link 108; alternatively, controller 141 may have a da- 
tabase that allows it to make the allocations autono- 

40 mously. 

Each digital cellular switch 101 comprises one or 
more digital switching modules (DSMs) 1 20. A module 
120 structurally resembles a cell 102 in that it com- 
prises a TDM bus 130 which is similar to TDM bus 

45 1 40, a controller 131 which provides the same TDM 
bus control functions as controller 141 , and a plurality 
of interfaces 132 connected to bus 130 which provide 
the same functionality as interfaces 142. On the basis 
of control communications originating from ECP com- 

50 plex 1 34, controller 1 31 causes communications to be 
switched by TDM bus 130 between interfaces 132. 
Each trunk 107 extending from a cell 102 is terminat- 
ed at a switching module 120 by an interface 132. 
Other interfaces 132 at a module 120 terminate 

55 trunks 106, which are duplicates of trunks 107 butex- 
tend to public telephone network 100. 

If switch 101 includes more than one module 120, 
it also includes a time-multiplexed switch (TMS) 121. 
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Then a TMS interface 133 is connected to TDM bus 
130 in each module 120 and terminates a link 109 
which extends to TMS ,121. Interface 133 is illustra- 
tively the Module Control Complex (MCC) of an AT&T 
Definity communications system Universal Module. 5 
TMS 121 provides direct switched interconnection be- 
tween modules 120 of one mobile radio-telephone 
switch 101. Interconnection between modules 120 of 
different mobile radio- tele phone switches 101 is pro- 
vided by public telephone network 100 or by trunks 10 
that interconnect switches 101 directly. 

Overall control of a digital cellular switch 101 and 
coordination of activities between its modules 120 
and 121 is exercised by a DCS controller 161. DCS 
controller 161 is in direct communication with ECP 15 
complex 134 over a control link 108. Controller 161 
has its own control connection to TMS 121 through 
link 150, and to controllers 131 of switching modules 
120 through link 150 and TMS interfaces 133. Con- 
troller 161 is illustratively the 501 CC processor of an 20 
AT&T Definity communications system. 

Turning now to FIG. 2, it shows an illustrative ex- 
ample of a cellular mobile radio-telephone system 
constructed according to the invention. Same numer- 
ical designations as were used in FIG. 1 are used in 25 
FIG. 2 to designate elements that are common to both 
systems. 

FIG. 2 shows a system topology that resembles 
the one of FIG. 1 in many respects, though it is not 
identical. The system of FIG. 2 includes a plurality of 30 
geographically-dispersed cells 202, each one of 
which provides radio-telephony services to mobile ra- 
dio-telephones 203 in its vicinity. As used herein, cell 

202 refers either to a geographically separate cell site 

or to one of a plurality of "faces on a given cell site, 35 
where a "face" is a cell sector as is typically imple- 
mented by using directional transmit antennas at a 
cell site. The operation of all mobile radio-telephones 

203 and cells 202 is synchronized to a common mas- 
ter clock, such as to timing signals generated and 40 
broadcast by a global positioning system satellite. In- 
terconnection between cells 202, and between cells 

202 and public telephone network 100, is accomplish- 
ed by digital cellular switches 201, in two stages. First, 
individual cells 202 are connected to one or more cell 45 
interconnect modules (CIMs) 209 of a DCS 201 by 
trunks 207. Cell interconnect modules 209 of individ- 
ual DCSs 201 are each in turn connected to each 
speech coding module (SCM) 220 of that DCS 201 by 
fiber-optic packet-switched trunks 210. Digital cellu- so 
lar switches 201 are each connected to public net- 
work 100 by a plurality of trunks 106, analogously to 
FIG. 1, and directly to each other by trunks 206 that 
functionally duplicate trunks 106. The operation of 
switches 201 is synchronized to master timing signals 55 
(not shown) of public telephone network 100. Further 
analogously to FIG. 1, cells 202 and digital cellular 
switches 201 operate under control of ECP complex 



134, to which they are connected by control links 108. 
Likewise, the vinous modules 209 and 220 of a DCS 

201 are connected by control links 208 to a common 
DCS controller 261 and operate under its control. 
Physically, DCS controller 261 is illustratively again 
the 501 CC processor. 

In the system of FIG. 2, some, but not necessarily 
all, mobile radio-telephones 203 are digital radio-tel- 
ephones. While illustratively shown as mounted in a 
vehicle, a mobile radio-telephone 203 may be any 
portable radio-telephone, and may even be a station- 
ary radio-telephone. The digital radio-telephones use 
voice-compression techniques to reduce the required 
digital transmission rate over the radio channel. Each 
digital radio-telephone includes voice-compression 
circuitry in its transmitter and voice-decompression 
circuitry in its receiver. Each radio-telephone is capa- 
ble of operating at any one of a plurality of wideband 
radio frequency pairs. 

For handling non-packetized traffic analogous to 
that handled by the system of FIG. 1, side-by-side 
with packetized traffic, a DCS 201 of the system of 
FIG. 2 includes the elements shown in dashed lines: 
a TMS 121 connected by trunks 109 to modules 209 
and 220, and trunks 106 connecting CIMs 209 directly 
to public telephone network 100. Their use is enlight- 
ened further below. 

Digital radio-telephones 203 may operate in one 
or more of time-division multiple-access (TDMA) 
mode or code-division multiple-access (CDMA) mode 
or some other digital or analog radio mode. TDMA is 
a technique, known in the art, that provides multiple 
users access to a radio channel (frequency) by divid- 
ing that channel into multiple rime slots. A single user 
can be assigned to one or more of these time slots. A 
TDMA radio 203 is illustratively the TIA IS54 digital 
cellular radio. TDMA employs different frequencies in 
adjacent cells and therefore requires the "hard hand- 
off" procedure described previously. 

In the present illustrative example, digital radio- 
telephones 203 are assumed to operate in CDMA 
mode, or as a fallback in the FDMA (analog) mode. 
CDMA is a direct-sequence spread-spectrum techni- 
que which allows reuse of the frequencies in the ter- 
ritories served by adjacent cells 202. Consequently, 
adjacent cells 202 need not, and do not, operate at 
different radio frequencies, but re-use the same fre- 
quencies. When moving from the vicinity of one cell 

202 to the vicinity of another cell 202, a mobile radio- 
telephone 203 may undergo a "hard handoff proce- 
dure, described previously. However, a CDMA mobile 
radio-telephone 203 in the system of FIG. 2 may al- 
ternatively and preferentially undergo a "soft handoff 1 
procedure, during which it communicates with both of 
the cells 202 on the same frequency pair at the same 
time. The CDMA technique and its associated proce- 
dures and equipment are also known in the art. The 
basic principle of direct-sequence code-division mul- 
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tiple-access is the use of a plurality of individual and 
distinct high-speed digital signals which are absolute- 
ly or statistically orthogonal to each other, each to 
modulate one of a plurality of low-speed (i.e., base- 
band) user signals and to combine the plurality of 5 
modulated signals into common digital signals which 
then are used to control radio frequency modulation 
functions. Recovery and separation of the original 
baseband signals is accomplished using the corre- 
sponding digital modulation signals to demodulate 10 
within a time-synchronous manner. For a description 
of CDMA see, e.g., U. S. Patent No. 4,901,307, and 
published international patent applications WO 
91/07020, WO 91/07036, and WO 91/07037. 

A cell 202 is shown in FIG. 3. Similarly to a cell 15 
102 of FIG. 1, cell 202 includes TDM bus 140 operat- 
ing under control of controller 241, and DS1 interfaces 

242 couple TDM bus 140 to trunks 207. Controller 241 
is illustratively the control complex of an AT&T Auto- 
plex Series II cell site. It functionally duplicates con- 20 
trailer 141 of a cell 102. but now performs additional 
functions, described below, on account of the fact that 

cell 202 comprises a plurality of digital radios 243. Ev- 
ery digital radio's signal input and output are inter- 
faced to TDM bus 140 by corresponding one or more 25 
channel elements 245 and a cluster controller 244. A 
channel element 245 is an interface to digital radios 

243 serving an individual user. Channel elements 245 
provide signal processing functions - baseband and 
spread-spectrum (CDMA) signal processing func- 30 
tions in this example -- for individual calls being trans- 
mitted and received by their associated radios 243. 

Each cluster controller 244 includes a C-bus 390. 
C-bus 390 is illustratively a conventional computer in- 
put and output (I/O) bus, and channel elements 245 35 
are connected to C-bus 390 as computer I/O devices. 
C-bus 390 and channel elements 245 operate under 
control of a controller 393. Controller 393 is illustra- 
tively a general-purpose microprocessor, and it is 
served by a bus 391 which is illustratively a conven- 40 
tional microprocessor main bus. Bus 391 is connected 
to C-bus 390 by a C-bus interface 392 which functions 
as an I/O interface of conventional design. Controller 

393 orchestrates data movement between channel 
elements 245 and cell 202 TDM bus 140 (illustratively, 45 
one transfer in each direction for each channel ele- 
ment 245 every 20 msecs.), performs operation, ad- 
ministration, and maintenance (OA & M) functions on 
cluster controller 244, handles cell-site signalling and 
other specialized functions, and performs level-2 and so 
level-3 protocol formating and deformatting functions 

on data (call traffic and signalling) passing between 
channel elements 245 and TDM bus 140. A memory 

394 is connected to bus 391 and serves as a scratch- 
pad traffic-buffer memory and an instruction memory 55 
for controller 393. Also connected to bus 391 is an 
HDLC controller 395. it performs HDLC formating 

and deformating functions on traffic flowing between 



channel elements 245 and TDM bus 140, including 
traffic conversion between byte-oriented form used in 
cluster controller 244 and bit-oriented form used on 
TDM bus 140, including bit stuffing and LAPDflag in- 
sertion functions. HDLC controller 395 receives and 
transmits HDLC serial bit streams from/to TDM bus 
140 through a TDM bus interface 396, of conventional 
design, which connects controller 395 to bus 140. 

* Compressed call traffic and signalling are trans- 
ported between channel elements 245 and cluster 
controller 244 in the form of segments of byte- 
oriented information. Each channel element 245 
transmits and receives a segment of byte-oriented in- 
formation at regular intervals, illustratively every 20 
msecs. Cluster controller 244 formats each segment 
of byte-oriented information in LAPD protocol format 
which includes a level-3 protocol, for transmission to 
DCSs 201 . While any suitable level-3 protocol may be 
used, illustrative level-3 protocols 350 and 351 are 
shown in FIGS. 9 and 10. 

FIG. 9 shows a protocol 350 that is used to con- 
vey either call traffic or signalling or both, while FIG. 
10 shows a protocol 351 that is dedicated to convey- 
ing a particular type of signalling. Both protocols 350 
and 351 are coded by frames of FIGS. 7 and 8.A!evel- 
3 protocol data unit coded over a level-2 protocol is 
commonly referred to as a packet, and a level-2 pro- 
tocol data unit is commonly referred to as a frame. 
Protocol 350 of FIG. 9 comprises at least the informa- 
tion yields 320-327. Additional fields for other types of 
information may be included in packet 350, but these 
are not germane to the present discussion. Sequence 
number field 320 carries a sequential number of this 
packet 350 within the sequence of packets transmit- 
ted in a given direction. In the case of packet 350 out- 
going to a channel element 245 from a DCS 201, the 
sequence numbers begin at 0 at the start of every 
new call. In the case of packets 350 incoming from a 
channel element 245 to a DCS 201, the sequence 
numbers are derived from the master timing signals to 
which all mobile telephones 203 and cells 202 are 
synchronized. Packet type field 321 identifies the 
packet type as either a traffic packet, corresponding 
to packet 350 of FIG. 9, or a signalling packet, corre- 
sponding to packet 351 of FIG. 10. Clock adjust field 
322 carries information from cluster controllers 244 to 
DCSs 201 that is used to compensate for real and vir- 
tual soft between the master clock to which mobile tel- 
ephones 203 and cells 202 are synchronized and a 
master clock to which public telephone network 100 
and DCSs 201 are synchronized. Field 322 is used 
only in the reverse direction, and is null in the forward 
direction. Air CRC field 323 is the result of a conven- 
tional check-sum, computed by a mobile telephone 
203 over its transmitted traffic, and is sent by mobile 
telephone 203 along with that traffic. Signal quality 
field 324 carries reports computed by channel ele- 
ments 245 on the quality of call-traffic signals that 
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they are receiving from mobile telephone 203. Fields 
323 and 324 are also used only in the reverse direc- 
tion and are null in the forward direction. Power con- 
trol field 325 carries information from a cell 202 con- 
cerning the trend of power control instructions sent by 5 
a channel element 245 to its corresponding mobile 
telephone 203. Normally, this field is also used only 
in the reverse direction, but is used in both directions 
during soft handoff, as will be explained further be- 
low. Voice/signalling type field 326 identifies the type 10 
of information that is carried by packet 350: voice traf- 
fic only, voice plus signalling, or signalling only. And 
voice/signalling data field 327 carries call voice traffic 
or signalling information, or a mix of both, to and from 
channel elements 245. 15 

A signalling packet 351, shown in FIG. 10, is sim- 
pler than traffic packet 350 of FIG. 9: it has fields 321 
and 328-331 that are relevant to this discussion. 
Packet type field 321, already discussed in conjunc- 
tion with FtG. 9, identifies packet 351 as a signalling 20 
packet. Message type field 328 identifies the type of 
signalling coded by packet 351. Channel element ID 
field 329 identifies the particular channel element 245 
participating in this message exchange. Frame selec- 
tor ID field 330 identifies a particular virtual port on a 25 
processor 602 (see FIG. 6) participating in this mes- 
sage exchange. These fields 329 and 330 may be 
used for security, maintenance, performance track- 
ing, billing, routing, etc. Channel element 245 and 
frame selector IDs are assigned administratively at 30 
system configuration time, and remain fixed there- 
after. And signalling data field 331 carries the signal- 
ling information that is being conveyed. 

A cluster controller 244 couples a plurality of 
channel elements 245 to TDM bus 140. Each cluster 35 
controller 244 communicates on TDM bus 140 
through an allocated input and an output "pipe". The 
allocation is administrable, and is typically done at 
system initialization. Each "pipe" illustratively consti- 
tutes a plurality of (e.g., four) time slots (i.e., four 64 40 
Kbps channels) on TDM bus 140. In the reverse (in- 
bound) direction, cluster controller 244 queues traffic 
segments received from channel elements 245, for- 
mats them into packets, wraps the packets into invert- 
ed-HDLC-format LAPD (level-2 protocol) frames, and 45 
transmits the LAPD frames one after another into its 
allocated output -pipe" on TDM bus 140. In the for- 
ward (outbound) direction, cluster controller 244 re- 
ceives LAPD frames from its allocated input "pipe" on 
TDM bus 140, terminates the LAPD protocol, defor- so 
mats the packets, and then distributes the contents of 
these packets to channel elements 245 according to 
an address field embedded in the received frames. As 
a consequence of the operations of cluster controllers 
244, frames being conveyed to and from them are 55 
statistically multiplexed onto TDM bus 140, thereby 
greatly increasing the traffic-carrying capacity of the 
bandwidth of TDM bus 140 over alternative transmis- 



sion techniques. 

An illustrative LAPD frame 300 is shown in FIG. 
7. For purposes of this discussion, it comprises a plur- 
ality of fields 301-305: a hay field 301 , used for delim- 
iting frames; a Data Link Connection Identifier (DLCI) 
field 302; a control field 303 which specifies the type 
of LAPD frame this is; a user data field 304 which con- 
tains the level-3 protocol (packet) 350 or 351 referred 
to above; and a frame check sequence (FCS) field 
305, used for error checking. The DLCI field 302 is the 
frame end-to-end address field. It contains a virtual 
link number or index (DLCI) that associates the frame 
with a particular call. In the forward direction, the 
DLCI identifies a particular channel element 245; in 
the reverse direction, the DLCI identifies a particular 
one of a plurality (illustratively two) of virtual ports of 
processor 602 which correspond to a particular 
speech processing unit 264 service circuit 612 (see 
FIG. 6). Within a cluster controller 244, the DLCI iden- 
tifies the channel element 245 which is the source or 
destination of the frame. In this embodiment, DLCIs 
are assigned to ports and channel elements adminis- 
tratively at system confirmation time, and remain 
fixed thereafter. 

The transmission of frames to and from cluster 
controllers 244 is effected using the frame-relay tech- 
nique of transmission, whereby protocol termination 
of the frames occurs only at the transmission en- 
dpoints, thereby greatly increasing the efficiency and 
speed of those frame transfers through the system of 
FIG. 2. The frame-relay technique is described in U. 
S. Patent No. 4,894,822. It is hereby incorporated 
herein by reference. 

Advantageously, in order to provide radio tele- 
phone services to conventional analog or digital 
TDMA mobile telephones 103 within the same sys- 
tem, analog FM or TDMA digital radios 143 may also 
be connected to TDM bus 140 in cells 202, in the man- 
ner described for cells 102, as suggested by the dash- 
ed blocks in FIG. 3. Alternatively, conventional cells 
102 may be used side-by-side with cells 202 within 
the system of FIG. 2. TDMA traffic may be carried 
through the system of FIG. 2 either in circuit-switched 
form, like the analog radio traffic, or in packet- switch- 
ed form, like the CDMA traffic. 

In the cell 202 of FIG. 3, DS1 interfaces 242 per- 
form their conventional functions of gathering 64 
Kbps time slots from TDM bus 140 and multiplexing 
them into DS1 format for transmission on trunks 207, 
and vice versa. It is important for purposes of this ap- 
plication that each interface 242 ensure that the delay 
undergone by signals of every DS0 channel within in- 
terface 242 be constant; many commercial DS1 inter- 
faces, such as the AT&T TN 464C, do in fact meet this 
condition. On account of the functions performed by 
cluster controllers 244, frames are statistically multi- 
plexed onto trunks 207 and the format of facilities that 
implement trunks 207 is, from a logical perspective, 
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no longer the purely conventional DS1 format of facili- 
ties that implement trunks 107 of FIG. 1: as opposed 
to comprising 24 independent DSO channels, as it 
does on DS1 facilities, each facility now comprises 
multiple independent "pipes" each consisting of the 5 
bandwidth of one or more DSO channels. Each of the 
"pipes" carries the LAPD frames created by or des- 
tined for a single cluster controller 244. The traffic- 
carrying capacity of the bandwidth provided by trunks 
207 is thereby greatly increased over alternative w 
transmission techniques, such as the conventional 
circuit-switching technique. Any remaining trunks 207 
(i.e., DSO channels) that are not bundled into "pipes" 
continue to be used on an independent individual cir- 
cuit-switched basis, e.g., to carry communications to 15 
and from conventional radios 143. 

A cell interconnect module (CIM) 209 is shown in 
FIG. 4. Cell interconnect module 209 is illustratively 
founded on the Universal Module of the AT&T Def inity 
communications system. It includes a local area net- 20 
work (LAN) bus 250 operating under control of a con- 
troller 251 . Universal DS1 (UDS1) interfaces 252 con- 
nect trunks 207 to LAN bus 250. Each interface 252 
includes a DS1 trunk interface 442 which duplicates 
the DS1 facility-interface circuitry of DS1 interface 25 
242, and a packet processing element (PPE) 401 , in- 
terconnected by a concentration highway 400. Con- 
centration highway 400 is a time-division multiplexed 
bus of 64 time slots each having a 64 Kbps rate. The 
DS1 trunk interface 442 performs the functions of 30 
gathering 64 Kbps time slots from concentration high- 
way 400, inverting the inverted HDLC format (dis- 
cussed in conjunction with cell 202 of FIG. 3) back to 
normal, and multiplexing the data into DS1 format for 
transmission on trunks 207, and vice versa. 35 

PPE 401 performs LAPD frame-relay functions 
between concentration highway 400 and LAN bus 
250. PPE 401 includes a translation table 411 that 
contains a board and a port address for each DLCI 
302. Translation table 411 is administered at initializa- 40 
tion. PPE 401 is administered to receive LAPD frames 
300 on designated time slots of concentration high- 
way 400. For each LAPD frame 300 received on con- 
centration highway 400, PPE 401 uses the contents 
of the frame's DLCI field 302 to find the correspond- 45 
ing board and port address in table 411. The board 
and port addresses identify the intended recipient of 
frame 300 on LAN bus 250. PPE 401 then strips flag 
field 301 from frame 300 and prepends the found 
board and port addresses to the frame to form a modi- so 
f ied LAPD frame 31 0 shown in FIG. 8. A comparison 
with FIG. 7 shows flag field 301 to have been replaced 
by board address 311 and port address 312. PPE 401 
then transmits mounted LAPD frame 310 on LAN bus 
250. In the other direction, PPE 401 examines modi- 55 
f ied LAPD frames 310 transmitted on LAN bus 250 for 
its board address 311 . It receives any frame 310 hav- 
ing the looked-for address 311, stips the addresses 



311 and 312 from frame 310, replaces them with flag 
field 301 to form a LAPD frame 300, and then trans- 
mits frame 300 on concentration highway 400. The 
stripped-off port address 312 identifies to PPE 401 
the particular time slots on which that particular frame 
300 is to be transmitted. 

Also connected to LAN bus 250 of cell intercon- 
nect module 209 are expansion interfaces (Els) 253. 
Each expansion interface 253 couples an optical fiber 
trunk 210 to LAN bus 250. Expansion interfaces 253 
merely act as routing elements. Each expansion inter- 
face 253 includes a LAN bus interface 450 which 
monitors LAN bus for modified LAPD frames 310 hav- 
ing a pre-administered DLCI 302, board address 311, 
and port address 312. Interface 450 captures any 
frame 310 having the looked-for DLCI 302, board ad- 
dress 311, and port address 312, strips off the pre- 
pended board address 311, and stores the frame 310 
in a FIFO buffer 451. FIFO buffer 451 outputs the pre- 
pended port address 312 and DLCI 302 of the frame 
310 to a translation table 452, and outputs fields 302- 
305 of frame 310 to a translation inserter 453. Table 
452 is a pre-administered table of board and port ad- 
dresses of speech coder modules 220. Table 452 
uses the port address 312 and DLCI 302 that it re- 
ceives from FIFO buffer 451 as a pointer to find a new 
board address 311 and port address 31 2 for the frame 
310, and sends the new addresses 311 and 312 to 
translation inserter 453. Inserter 453 prepends the 
new board and port addresses 311 and 312 received 
from table 452 to the frame 310 fields that it received 
from FIFO buffer 451, and sends the new frame 310 
to fiber interface 454. If no corresponding addresses 
are found in and sent from table 452, inserter 453 
merely discards the received frame 310. Fiber inter- 
face 454 transmits the frame 310 on optical fiber trunk 
210. Any desired protocol and transmission format 
may be used on trunks 210. In the reverse direction, 
fiber interface 454 receives frames 310 on trunk 210 
and stores them in a FIFO buffer 455. LAN bus inter- 
face 450 extracts the stored frames 310 from FIFO 
buffer 455 and transmits them on LAN bus 250. Con- 
sequently, expansion interface 253 merely transmits 
on LAN bus 250 those frames 310 that it receives on 
the attached fiber trunk 210. These frames 310 have 
board addresses 311 that identify the destination in- 
terfaces 252 on LAN bus 250, and port addresses 
312 that are not looked for by any expansion interfac- . 
es 253 on LAN bus 250. 

For purposes of handling conventional, circuit- 
switched, cellular radio telephone communications, 
cell interconnect module 209 includes elements 
shown in dashed lines in FIG. 4. Specifically, CIM 209 
includes a TDM bus 230 which duplicates TDM bus 
130, and each UDS1 interface 252 includes a time- 
slot interchanger (TSI) 402 which couples concentra- 
tion highway 400 to TDM bus 230. TSI 402 performs 
conventional time-slot interchange functions. It re- 
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ceives designated 64 Kbps channels (time slots) on 
concentration highway 400 and TDM bus 230 and 
transmits them on designated time slots of TDM bus 
230 and concentration highway 400, respectively. TSt 
402 is programmed on a per-call basis. For the pur- 5 
pose of switching these conventional communica- 
tions, TDM bus 230 is coupled by a TMS interface 1 33 
and trunk 109 to a TMS 121 (see FIG. 2), in the man- 
ner described for FIG. 1. For the purpose of connect- 
ing these conventional communications to public tel- 10 
ephone network 100, TDM bus 230 is also coupled by 
a DS1 interface 132 and a trunk 106 to network 100. 

A speech coder module 220 of a digital cellular 
switch 201 is shown in FIG. 5. Each DCS 201 compris- 
es one or more identical modules 220. Module 220 is 15 
illustratively the Universal Module of AT&T Definity 
communications system. Module 220 includes TDM 
bus 130 and a LAN bus 260 which is a duplicate of 
LAN bus 250, both operating under control of a con- 
troller 231. As in FIG. 1, TDM bus 130 is connected 20 
by DS1 interfaces 132 and trunks 106 to public tele- 
phone network 100. Fiber trunks 210 from cell inter- 
connect modules 209 are connected to LAN bus 260 
by expansion interfaces 263 which duplicate expan- 
sion interfaces 253. Each cell interface module 209 of 25 
a DCS 201 is connected to each speech coder module 
220 of that DCS 201. Interconnection between DCSs 
201 is provided by network 100 through trunks 106. 

Buses 260 and 130 are interconnected through a 
plurality of call-processing nodes referred to herein as 30 
speech processing units (SPUs) 264. Based on the 
board address 311 prepended to each frame 310 by 
expansion interfaces 253 of cell interconnect mod- 
ules 209, each speech processing unit 264 receives 
frames 310 that are addressed to it, depacketizes 35 
their contents (i.e., terminates their protocol), per- 
forms vinous processing functions - including 
speech decompression on the contents of each re- 
ceived frame, and outputs the processed frame con- 
tents on TDM bus 1 30 in time slots which are assigned 40 
to calls on a call -by-call basis. In the reverse direction, 
a speech processing unit 264 receives communica- 
tions over TDM bus 130 in time slots which are as- 
signed to calls on a call-by-call basis, performs vari- 
ous processing functions -- including speech com- 45 
pression — thereon, packetizes the processed com- 
munications, includes in each frame a DLCI 302 iden- 
tifying a particular channel element 245 of a particular 
cell 202, prepends to each frame board and port ad- 
dresses 311 and 312 that identify the frame's destin- so 
ation on LAN bus 260. and transmits the frames 310 
on LAN bus 260. 

As a consequence of the operations of cell inter- 
connect modules 209 and speech coder modules 
220, frames 310 being conveyed between them are 55 
statistically multiplexed onto, and frame-relayed over, 
trunks 210, thereby greatly increasing the traffic-car- 
rying capacity of the bandwidth provided by trunks 



210 over alternative transmission techniques such as 
circuit-switching. 

As was mentioned in conjunction with FIG. 3, 
DCS 201 optionally includes a TMS 121 for servicing 
conventional radio telephone communications. 
Speech coder module 220 is connected to TMS 121 
by a trunk 109 and a TMS interface 133, in the man- 
ner described for switching modules 120 of FIG. 1. 

An illustrative speech processing unit 264 is 
shown in FIG. 6. Each SPU 264 includes a LAN bus 
interface 601. It monitors frames 310 traversing LAN 
bus 260 for pre-administered board addresses 311, 
and captures those having the sought- for addresses 
311. LAN bus interface 601 includes a buffer 620. 
Upon capturing a frame 310, LAN bus interface 601 
appends to it a time stamp, stores it in the buffer 620, 
and issues an interrupt to a processor 602. The time 
stamp is the present count of a counter 623, dis- 
cussed further below. 

The port address 312 of a frame 310 identifies 
one of a plurality of service circuits 612 implemented 
by SPU 264. A service circuit 612 is assigned to a call 
either for the duration of the call or until a hard handoff 
occurs. Each service circuit 612 has its own audio- 
processing circuitry. But all service circuits 612 are 
served on a time-shared basis by processor 602, 
which performs frame-selection and protocol- proc- 
essing functions for all service circuits 612 of an SPU 
264. The functions performed by processor 602 on 
frames 310 received from LAN bus interface 601 are 
shown in FIGS. 11-14, and 17-18, and functions per- 
formed by processor 602 on traffic segments (here- 
inafter also referred to as traffic frames) received 
from service circuits 612 are shown in FIG. 15. Proc- 
essor 602 performs each of these functions for each 
service circuit 612 every 20 msecs. The performance 
of the functions is interrupt-driven, by interrupt sig- 
nals provided by an adaptive synchronization circuit 
611 and interface 601. 

The exchange of traffic frames of incoming and 
outgoing call traffic is coded on between processor 
602 and service circuits 612 through buffers 603 of 
processor 602. Each service circuit 612 has its own 
corresponding buffer 603. A buffer 603 buffers traffic 
frames passing between processor 602 and a vocod- 
er 604 of a service circuit 61 2 to compensate for minor 
differences and fluctuations in the timing of input and 
output operations of processor 602 and vocoder 604. 

Each service circuit 612 has its own vocoder 604. 
Vocoders 604 provide voice compression and decom- 
pression functions. Each is a digital signal processor 
that receives a traffic frame of compressed speech 
from processor 602 via buffer 603 at regular intervals 
(e.g., every 20 msecs.) and decompresses the traffic 
frame into a predetermined number (e.g., 160 bytes) 
of pulse-code-modulated (PCM) speech samples. 
Each byte has a duration of 125 usees, in this exam- 
ple, referred to as a "tick". In the opposite direction, a 
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vocoder 604 receives 160 bytes of PCM speech sam- 
ples, performs speech compression functions there- 
on, and outputs a traffic frame of the compressed 
speech to processor 602 via buffer 603 at regular in- 
tervals (every 20 msecs.)- Exchanges of traffic 
frames between vocoder 604 and processor 602 are 
timed by clock signals generated by vocoder 604 in- 
ternal input and output clocks 621 and 622, while re- 
ceipt and transmission of PCM samples by vocoder 
604 are timed by clock signals generated by a clock 
circuit 600. Clocks 621 and 622 are edge- 
synchronized with circuit 600 clock signals at system 
initialization and service circuit 612 reset. Vocoders 
are well known in the art. Each vocoder 604 is illus- 
tratively implemented using the AT&T 16A digital sig- 
nal processor (DSP) which embodies the Qualcomm, 
Inc. QCELP low-bit-rate variable-rate speech encod- 
ing/decoding algorithm. The QCELP algorithm pro- 
vides for sending minimal information during periods 
of low or no speech activity. The frame transport 
mechanism of this embodiment ideally adapts to time- 
varying traffic loads. 

In the case of a system handling both CDMA and 
TDMA traffic wherein the TDMA traffic is also frame- 
relayed, some of the service circuits 612 are dedicat- 
ed to handling the TDMA traffic, and U.eir vocoders 
604 are illustratively the AT&T 16A digital signal proc- 
essor programmed according to the TIA IS-54 stan- 
dard for TDMA communications. 

PCM samples on their way from vocoders 604 
pass through tone-insertion circuits 605. Each ser- 
vice circuit 612 has its own tone-insertion circuit 605. 
Upon command from processor 602, a tone-insertion 
circuit 605 momentarily blocks and discarding PCM 
samples output by vocoder 604, and in their place 
substitutes PCM samples of whatever Touch-Tone 
signals were specified by the command. Tone- 
insertion circuit 605 has no effect on PCM samples 
being input to vocoder 604. Operation of tone- 
insertion circuit 605 is synchronized with the output of 
vocoder 604 by clock signals generated by clock cir- 
cuit 600. 

Tone-insertion circuits 605 are followed in the se- 
quence of service circuit 61 2 circuitry by echo cancel- 
lers 606. Each service circuit 612 has its own echo 
canceller 606. Each cancels echoes of telephone net- 
work 100 - bound call traffic from telephone network 
100 - originated call traffic, by keeping an attenuated 
copy of the vocoder-generated network-bound traffic 
and subtracting an appropriately-delayed copy from 
received network-bound traffic. Echo cancellers are 
well known in the art Timing of echo canceller 606 op- 
erations is controlled by clock signals generated by 
clock circuit 600. 

Echo cancellers 606 receive network-originated 
traffic from, and transmit network-bound traffic to, a 
concentration highway 607. Concentration highway 
607 is a passive serial TDM bus that carries 64 kbps 



time slots. Each echo canceller 606 is statically as- 
signed its own input time slot and its own output time 
slot on concentration highway 607. 

Concentration highway 607 is coupled to TDM 

5 bus 130 by a TDM bus interface 608. Interface 608 
performs time-slot interchange (TSI) functions be- 
tween highway 607 and bus 130. Its operation is 
rimed by clock signals generated by circuit 600, and 
is controlled by a translation and maintenance (XLA- 

10 TION. AND MTCE.) unit 609. Unit 609 performs high- 
way 607-to-bus 130 time-slot assignment functions 
on a per-call basis, under the direction of controller 
231 of that speech coder module 220. Unit 609 com- 
municates with controller 231 via a control channel 

15 implemented by bus 130. This control channel is in- 
terfaced to unit 609 through interface 608 and bus 
613. Unit 609 provides maintenance functions to LAN 
bus interface 601 via control link 616. 

Unit 609 exerts control over interface 608 via a 

20 translation and maintenance control bus 61 3, to which 
both are connected. Similarly, processor 602 controls 
circuits 601 , 603-606, and 611 via a processor control 
bus 610: Communications between processor 602 
and unit 609 are facilitated by a buffer 614 which cou- 

25 pies bus 61 0 with bus 61 3. 

Clock circuit 600 is connected to TDM bus 130 
and derives riming information therefrom, in a con- 
ventional manner. Clock circuit 600 distributes this in- 
formation, in the form of clock signals of vinous rates, 

30 including 2.048 MHz, 8 KHz, and 50 Hz (correspond- 
ing to intervals of 500 nsec, 125 usee, and 20 msec, 
intervals, respectively), all of which are synchronized 
with each other, via a clock bus 615 to circuits 604- 
606, 608, and 611, in order to synchronize their oper- 
as ation with TDM bus 130. Clock circuit 600 also distrib- 
utes this information to LAN bus interface 601 for bit- 
time synchronization of LAN bus 260. Operation of 
TDM bus 130 is synchronized to network 100 -- 
hence, clock circuit 600 synchronizes operations of 

40 the various elements with the master clock of network 
100. 

Adaptive synchronization circuit 611 uses the 
clock signals obtained from clock circuit 600 to gen- 
erate clock signals which are synchronized in fre- 

45 quency with, but are offset in phase - in amounts con- 
trolled by processor 602 ~ from, the 20 msec, clock 
signals generated by clock circuit 600. These offset 
clock signals are used to time the operations of proc- 
essor 602. The generation and use of these offset 

so clock signals is explained further below. Physically, 
circuits 611 and 600 may be implemented as a single 
device. 

Circuit 611 also includes a present-time counter 
623. Counter 623 increments its count once every 
55 PCM sample tick, e.g., once very 125 usees. This 
count is reset by every 50 Hz clock pulse from clock 
circuit 600, e.g., every 20 msecs. Counter 623 thus in- 
dicates present time relative to signals generated by 

12 
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clock circuit 600. A second portion of counter 623 
keeps a modulo-8 count that is incremented by the 20 
msec, clock pulses that reset the 125 usee, count. 
Counter 623 provides its counts to LAN bus interface 
601 for use as a time stamp of received frames 310. 5 

Discussion now returns to processor 602 and its 
packet-and frame- processing functions. (Level-2 pro- 
tocol processing is commonly referred to as frame 
processing, while level-3 protocol processing is com- 
monly referred to as packet processing.) The func- 10 
tions performed by processor 602 on frames 310 re- 
ceived from LAN bus 260 are shown in FIGS. 11-14. 
Processor 602 performs these functions for each ser- 
vice circuit every 20 msecs. Performance of different 
ones of these functions for a particular service circuit 15 
612 is triggered by receipt of corresponding receive 
interrupt signals from LAN bus interface 601 and 
adaptive synchronization circuit 611. 

As was mentioned above, upon receiving a frame 
addressed to the corresponding SPU 264, LAN bus 20 
interface 601 appends a time stamp to the received 
frame, stores the received frame in buffer 620, and is- 
sues an interrupt to processor 602. Upon being in- 
voked by the receive interrupt signal from LAN bus in- 
terface 601, at step 900, processor 602 retrieves the 25 
received frame from buffer 620 of LAN bus interface 
601, at step 902. Processor 604 then performs con- 
ventional level-2, i.e., LAPD protocol, processing on 
the frame, at step 904. This processing may include 
acknowledging receipt of the frame. Upon completing 30 
level-2 processing, processor 604 checks control 
field 303 to see if this is a ievel-2 only frame (e.g., a 
loop-around test frame), at step 906. If so, processing 
of the frame is completed, and processor 602 merely 
returns to the point of its invocation, at step 908. But 35 
if this is not a level-2 only frame, i.e., its user data field 
304 carries a level-3 protocol, processor 602 uses the 
frame's DLCI 302 to select from its memory the stored 
call state of the call to which the frame pertains, at 
step 910. Next, processor 602 checks, at step 911. 40 
packet type field 321 of the received level-3 protocol 
to determine the packet type: traffic or signalling. If 
field 321 identifies the packet as a signalling packet, 
it means that the packet carries cell-to-switch signal- 
ling information, i.e., signalling intended for DCS 201 . 45 
Processor 602 therefore performs the signalled func- 
tion, at step 970, This may be any one of 3 functions: 
to update call state by either setting up or tearing 
down a call or tiding or removing a second cell in soft 
handoff, to insert tones into the telephone network- 50 
bound portion of the call, or to perform initial clock 
synchronization (discussed in conjunction with FIG. 
1 7). Processor 602 then returns to the point of its in- 
vocation, at step 946. Voice/signalling packets 350 
are sent and received at 20 msec, intervals, while sig- 55 
nailing-only packets 351 may be sent at any time as 
required to send signalling information. 

If field 321 identifies the packet as a traffic pack- 



et, processor 602 performs clock adjustment and syn- 
chronization functions, at step 912, to shift the offset 
of clock signals generated by circuit 611 from clock 
signals generated by circuit 600 by an amount deter- 
mined by processor 602 or dictated by clock adjust 
field 322 of the received packet. These are described 
in conjunction with FIG. 18. Processor 602 then 
checks voice/signalling type field 326 of the received 
level-3 packet, at step 914, to identify the type of in- 
formation coded by the packet: voice only, voice plus 
signalling, or signalling only. If the traffic packet is a 
voice-only packet, processor 602 checks the re- 
trieved call state to determine if the call is in soft hand- 
off, at step 916. If not, processor 602 checks air CRC 
field 323 of the frame (containing the result of a check- 
sum computed over the CDMA transmission between 
cell 202 and mobile telephone 203), at step 918. If the 
air CRC does not check out, it means that the packet 
carries defective information, and so processor 602 
discards the packet, at step 923, and then returns, at 
step 946. Vocoder 604 will mask the loss of that traf- 
fic. If the air CRC checks out at step 918, processor 
602 checks signal quality field 324 of the packet to de- 
termine whether the voice quality meets a predeter- 
mined threshold value, at step 91 9. If the voice quality 
does meet the threshold value, processor 602 marks 
the packet as "good" by appending a command there- 
to, at step 920, stores the packet of voice information 
in buffer 603 which is allocated to the appropriate ser- 
vice circuit 61 2, at step 922, and then returns to the 
point of its invocation, at step 926. If the voice quality 
does not meet the minimum threshold value, proces- 
sor 602 marks the packet as "bad", at step 921 , stores 
the packet in buffer 603 of the appropriate service cir- 
cuit 612, at step 922, and then returns, at step 946. 

During the procedures just described, processor 
602 uses contents of sequence number field 320 of 
the received packet to detect and handle lost or out- 
of-sequence packets, in a conventional manner. 

Returning to step 916, if the call is in "soft hand- 
off\ processor 602 should be receiving two packets 
for the call every 20 msecs., each from a different cell 
202 but generally carrying identical information. So 
processor 602 checks whether it has yet received 
both duplicate packets, at step 932. The duplicate 
packets are identified by having the same sequence 
number in field 320. If not, meaning that processor 
602 has received either only one of the expected du-. 
plicate packets, or has received packets from both 
cells but being different sequence numbers, proces- 
sor 602 checks the sequence number of the just- 
received packet, at step 933, to determine whether its 
sequence number is greater than, equal to, or less 
than the expected sequence number. If the sequence 
number of the received packet is greater than the ex- 
pected sequence number, processor; 602 stores the 
received packet, at step 934, updates the associated 
call's state to indicate that one of the packets that will 
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be expected in the future has been received, at step 
935, and returns, at step 946. Updating of the call 
state at step 935 includes storing the contents of pow- 
er control field 325 of the received packet. If the se- 
quence number of the received packet is equal to the 
expected sequence number, processor 602 proceeds 
to steps 918 et seq. to process the packet as descri- 
bed previously. And if the sequence number of the re- 
ceived packet is less than the expected sequence 
number, processor 602 discards the received packet, 
at step 936, and then returns, at step 946. Again, vo- 
coder 604 will mask the loss of that traffic. 

Returning to step 932, if processor 602 finds that 
it has received both expected packets, processor 602 
updates the call state to so indicate, at step 938. This 
includes storing the contents of power control field 
325 of the received packet. It then recieves the first- 
received expected packet (now stored in a buffer 603) 
and compares the air CRC and the signal quality in- 
dicia of both packets to determine which packet is bet- 
ter, at step 940. Processor 602 then checks the voice 
quality field of the better packet to determine whether 
the voice quality meets a predetermined threshold 
value, at step 941. If not, processor 602 marks the 
better packet as "good" by appending a command 
thereto, at step 943; if so, processor 602 marks the 
better packet as "bad", at step 942. Processor 602 
then discards the worse packet and stores the better 
packet in buffer 603 of the corresponding call chan- 
nel, at step 944. Processor 602 then returns, at step 
946. 

Turning to FIG. 12, following step 946, when proc- 
essor 602 is invoked at step 950 by a receive interrupt 
signal RX_INT_X for a particular (Xth) service circuit 
612, processor 602 checks buffer 603 corresponding 
to that service circuit 612 to determine if buffer 603 is 
empty, at step 951 . If not, processor 602 retrieves the 
contents of that buffer 603 and passes the retrieved 
contents to vocoder 604 of that service circuit 612, at 
step 952. If buffer 603 is empty, processor 602 in- 
vokes a function in vocoder 604 of the appropriate 
service circuit 612 to mask the loss of the voice seg- 
ment coded by the discarded packet, at step 953. Vo- 
coder 604 masks the loss by generating at its output 
to circuit 605 PCM samples that it generates as a 
function of previously-received packets. Processor 
602 then returns to the point of its invocation, at step 
954. 

Returning to step 914, a traffic packetthat carries 
signalling information is encountered by processor 
602 only during "soft handoff", as under normal cir- 
cumstances signalling is sent directly to mobile tele- 
phone 203 from cell 202 involved in a given call. If the 
traffic packet carries only signalling information, 
processor 602 proceeds to step 955 of FIG. 1 3. There, 
processor 602 checks further contents of 
voice/signalling type field 326, to determine the sig- 
nalling direction: forward and/or reverse. If the direc- 



tion is forward, identifying the signalling as being or- 
iginated by a cell 202 and destined for a mobile tele- 
phone 203, processor 602 merely stores the packet, 
at step 956, and then returns, at step 970. If both sig- 

5 nailing functions are indicated, processor 602 stores 
the forward signalling, at step 957, and then proceeds 
to step 958. If the direction is reverse, identifying the 
signalling as being originated by a mobile telephone 
203 and described for cells 202, processor 602 

w checks, at step 958, whether it has received signalling 
packets from both sides (i.e., from both of the cells 
202 involved in the "soft handoff). If not, processor 
602 stores the packet, at step 960, and then updates 
the corresponding call's state to indicate that a signal- 

15 ling packet from one side has been received, at step 
962. Processor 602 then returns, at step 970. If the 
check at step 958 reveals that signalling packets from 
both sides have been received, processor 602 up- 
dates the corresponding call's state to so indicate, at 

20 step 964, and then compares the air CRC and signal 
quality yields 323 and 324 of the two packets to de- 
termine which packet carries the better quality sig- 
nals, at step 966. Processor 602 then discards the 
worse packet and stores the better one, at step 968, 

25 and then returns, at step 970. 

Returning to step 914, if processor 602 determi- 
nes that the packet carries both voice and signalling 
in formation, processor 602 proceeds to step 985 of 
FIG. 14, and performs signalling-processing steps 

30 985-998 of FIG. 14 which duplicate steps 955-968 of 
FIG. 13, and then proceeds to step 932 of FIG. 11 to 
perform the voice- processing steps. 

The functions performed by processor 602 on 
traffic frames (segments of voice information) re- 

35 ceived from vocoders 604 are shown in FIG. 1 5. Proc- 
essor 602 performs these functions for each service 
circuit 612 every 20 msecs. The performance of the 
functions for a particular service circuit 612 is also in- 
terrupt-driven, by receipt of a corresponding transmit 

40 interrupt signal provided by adaptive synchronization 
circuit 611. 

Upon being invoked by a transmit interrupt signal 
TX_INT_X to start processing for a particular (Xth) 
service circuit 612, at step 1200, processor 602 

45 checks the stored call state of the call that is being 
served by this service circuit 612 to determine wheth- 
er the call is in soft handoff, at step 1202. If not, proc- 
essor 602 accesses vocoder 604 of the service circuit 
6 1 2 that is being served and requests therefrom a 

so traffic frame of full-rate-coded call information, at 
step 1227. Upon receiving a traffic frame from that vo- 
coder 604, at step 1228, processor 602 formats the 
traffic frame in the level-3 protocol, at step 1230. This 
includes prepending a sequence number and a traffic 

55 type to the call traffic. Processor 602 then convention- 
ally encapsulates the formatted traffic frame in LAPD 
frame format, at step 1232, to form a LAPD frame 300 
(see FIG. 7). This includes retrieving the DLCI which 

14 
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is associated with the mobile-bound direction of the 
call and which identifies a particular channel element 
245 of a particular cell 202 (see FIG. 3) that is serving 
the call, and including it in LAPD frame 300. Proces- 
sor 602 then uses this DLCI to find in a table the board 5 
and port addresses 311 and 312 that correspond to 
this DLCI, and prepends the found addresses 311 and 
312 to LAPD frame 300 to form a modified LAPD 
frame 310 (see FIG. 8), at step 1234. Processor 602 
hands frame 310 over to LAN bus interface 601 for 10 
transmission onto LAN bus 260, at step 1236. Proc- 
essor 602 then returns to the point of its invocation, 
at step 1238. 

Returning to step 1202, if processor 602 determi- 
nes that the call is in soft handoff, it checks the stored 15 
call state of the call to determine whether any forward 
signalling is stored for this circuit, at step 1204. For- 
ward signalling would have been received only from 
the cell 202 that has been handling the call (referred 
to as the master cell 202) and stored at step 956 or 20 
957 of FIG. 1 3, or step 986 or 987 of FIG. 1 4. If forward 
signalling is not stored, processor 602 accesses vo- 
coder 604 of the service 612 circuit that is being 
served and requests therefrom a traffic frame of full- 
rate-coded communication information, at step 1206. 25 
But if forward signalling is stored, processor 602 must 
reserve room in a packet for the forward signalling in- 
formation, and so it accesses vocoder 604 and re- 
quests therefrom a traffic frame of only partial-rate- 
coded communication information, at step 1208. 30 

Vocoder 604 typically supplies traffic frames of 
full-rate-coded information, and it may not be able to 
respond to the request for a traffic frame of partial-ra- 
te-coded information instantly. Further, given a pause 
in speech activity, a partial-rate coded traffic frame 35 
may be supplied even if a full-rate- coded traffic frame 
has been requested. Processor 602 will check for this 
condition, at step 1218. 

When it has received a traffic frame from vocoder 
604, at step 1209, processor 602 duplicates the traffic 40 
frame, at step 1210, so as to have duplicate copies to 
send to both cells 202 that are involved in the soft 
handoff. At step 1212, processor 602 then recieves 
power control information that will have been stored 
at steps 935 and 938 of FIG. 11 from both cells 202 45 
that are involved in the soft handoff, swaps it so that 
each of the two cells 202 will be sent the power control 
information that was received from the iither of the 
two cells 202, and inserts the swapped information 
into the duplicate packets as power control field 325, so 
at step 1212. Processor 602 then checks the call's 
state to determine whether reverse signalling for the 
call has been received and stored at step 968 of FIG. 
1 3 or step 998 of FIG. 14, at step 1214. If reverse sig- 
nalling is available, processor 602 appends it to both 55 
of the duplicate packets, at step 1216. Following step 
1216, or if no reverse signalling is available, proces- 
sor 602 checks whether it had been supplied by vo- 



coder 604 with a frame of full-rate-coded or partial-ra- 
te-coded information, at step 121 8. If the traffic frame 
is full-rate-coded, it has no room for forward signalling 
information, and so processor 602 proceeds to steps 
1230 et seq. to format, packetize, and transmit both 
of the duplicate packets. Packetization at step 1234 
involves including in each duplicate packet's frame 
protocol 300 a different DLCI, so that the two packets 
will each travel to a different cell 202 involved in the 
soft handoff. Returning to step 1218, if the traffic 
frame is partial-rate-coded, processor 602 checks the 
call's state to determine whether forward signalling 
for the call had been received and stored at step 956 
of FIG. 1 3 or step 986 of FIG. 14, at step 1220. If for- 
ward signalling is available, processor 602 appends 
it to both of the duplicate packets, at step 1222. Fol- 
lowing step 1222, or if no forward signalling is avail- 
able, processor 602 proceeds to steps 1230 et seq. 

The synchronization of cell 202 and SPU 264 op- 
erations will now be explained in greater detail in con- 
junction with FIGS. 16-22. 

FIG. 19 represents the scenario for initial timing 
adjustments for traffic flow from network 100 to mo- 
bile radio-telephones 203. As was mentioned above, 
the operations of all mobile radio-telephones 203 and 
all channel elements 245 of all cells 202 are driven 
and synchronized to a common timing signal, which 
may be a signal broadcast by a global positioning sat- 
ellite. Each cell 202 derives therefrom a 20 msec, cell 
clock 1000 signal, which triggers each channel ele- 
ment 245 involved in a call to make a transmission to 
the corresponding mobile telephone 203 every 20 
msecs. at time 1300. A programmed, constant, offset 
(which may be zero) may exist for a given call (i.e., an 
offset between the rising edge of cell clock 1000 and 
time Tx 1 300). This constant offset affects the relative 
positions of signals 1304, 1307, 1308, and 1309 by 
the amount of said offset. 

In order to be able to transmit call traffic at time 
1300, a channel element 245 must receive that call 
traffic at least some minimum period of time prior to 
time 1300, at a time t mIn 1301. Channel element 245 
preferably receives the information for transmission 
within a time window 1302, which exists a little after 
time 1300 of the prior transmission and a little before 
time 1301 of the present transmission. Window 1302 
thus provides some leeway for minor time fluctu- 
ations. However, when a call is being established, it 
is uncertain when channel element 245 that is han- 
dling the call will receive a packet of call traffic for 
transmission from SPU 264. This is because, as was 
mentioned previously, the operations of mobile tele- 
phone switches 201 are controlled by a different clock 
than that of cells 202, which clock is not synchronized 
with, but is independent of, cell clock 1000. Further- 
more, other factors, such as differences in distances 
between mobile telephone switches 201 and different 
cells 202 and different traffic loads being conveyed 
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between them — and consequent different transmis- 
sion delays between them - also make the time of re- 
ceipt uncertain, therefore, when a call path is first es- 
tablished between a channel element 245 and an 
SPU 264 and null traffic begins to flow between them, 5 
packets from SPU 264 may be received by channel 
element 245 at times 1 303 that are outside of windows 
1302 and -in the worst case-- are after times t mtn 
1 301 . If that is the case, the channel element's corre- 
sponding channel controller 244 sends a signalling 10 
packet to SPU 264 indicating a need to adjust the time 
of transmission of packets from SPU 264 and also in- 
dicating the amount of time by which that transmission 
time must be adjusted to position the time of receipt 
of the packets at channel element 245 safely within 15 
windows 1302. 

The clock adjustment functions performed at cell 
202 are shown in FIG. 16. They constitute a proces- 
sor-performed routine invoked upon receipt of a pack- 
et at cluster controller 244. When the routine is in- 20 
voked, at step 1001, it checks whether the received 
packet is the first traffic packet received for the call, 
at step 1002. If so, the routine compares the time at 
which the packet was received with a window 1 302 
(the definition of which is stored in cluster controller 25 
244), at step 1004, to determine, at step 1006, when 
in relation to window 1302 the packet was received. 
If the packet was received substantially in the center 
of window 1302, no clock adjustment is necessary 
and the routine merely returns to the point of its invo- 30 
cation, at step 1022. if the packet was received too 
early, the routine causes a cell-to-switch type of sig- 
nalling packet to be sent to processor 602 of SPU 264 
that is handling the call, at step 1 008, requesting proc- 
essor 602 to delay the rime of the TX_INT_X inter- 35 
rupts for this call by a time, also specified in the pack- 
et, such as will move the time of receipt substantially 
to the center of window 1 302. Conversely, if the pack- 
et was received too late, the routine causes a cell-to- 
switch type of signalling packet to be sent to proces- 40 
sor 602, at step 1010, requesting that the time of the 
TXJNT_X interrupts for this call be advanced by a 
specified time. The routine then returns to the point of 
its invocation, at step 1 022. 

Alternatively, the routine need not respond mere- 45 
ly to the first traffic packet received, but may calculate 
an average time of required clock adjustment based 
on the receipt of a plurality of received traffic packets. 

Packet receive times 1303 at channel element 
245 correspond to packet transmit times 1 304 at SPU so 
264. As was mentioned previously, transmission of 
packets to channel element 245 from SPU 264 is trig- 
gered by transmit interrupt signals TX_INT_X issued 
to processor 602 by adaptive synchronization circuit 
611 . Consequently, adjustment of the packet receive 55 
times at channel element 245 by a certain amount re- 
quires an adjustment of TX_INT_X signals at circuit 
611 by the same amount. Therefore, when processor 

16 



602 receives the abovementioned signalling packet 
from channel element 245, it responds thereto at step 
970 of FIG. 11 by commanding adaptive synchroniza- 
tion circuit 61 1 to adjust the TXJNT signal for the cor- 
responding service circuit 612 by the specified 
amount. Circuit 611 obliges and shifts that transmit in- 
terrupt signal by the specified time period, designat- 
ed as 1310 in FIG. 19. Packet transmission time is 
thus shifted from times 1304 to times 1305 at SPU 
264, which corresponds to packet receive times 1306 
at channel element 245. Packet receive times 1 306 lie 
within windows 1302. 

However, in order to be able to transmit a packet 
at a given time, processor 602 must receive the traffic 
frame (segment of call traffic) which is included in that 
packet from vocoder 604 at some time prior to the 
transmit time. Packet transmit times 1304 correspond 
to frame receipt times 1 307, which in turn correspond 
to vocoder 604 traffic frame transmit times 1308, 
whereas shifted packet transmit times 1305 corre- 
spond to shifted traffic frame receipt times 1311, 
which in turn correspond to vocoder 604 traffic frame 
transmit times 1309. Consequently, processor 602 
must cause vocoder 604 to shift its traffic frame trans- 
mit times from times 1308 to times 1309. 

Vocoder 604 uses the output of an internal output 
clock 622 to time its traffic frame transmissions. Clock 
622 of an Xth service circuit 612 is initially synchron- 
ized to clock input signals received from clock circuit 
600. Processor 602 sends a command to vocoder 604 
to adjust the offset of its output clock 622 signals from 
the circuit 600 clock input signals by the abovemen- 
tioned time period 1310 that was specified in the sig- 
nalling packet which processor 602 received from 
channel element 245. Vocoder 604 does so, thereby 
shifting its traffic frame transmit times from times 
1308 to times 1309. The net result is that the asyn- 
chronous operations of channel element 245 and ser- 
vice circuit 61 2 and processor 602 have been syn- 
chronized with each other. 

The response scenario of processor 602 to re- 
ceipt of the clock-adjust signalling packet from cell 
202 is charted in FIG. 17. Upon determining that the 
received signalling packet requests clock adjustment 
to be performed, at step 1050, processor 602 checks 
contents of the packet to determine the direction in 
which the timing signals are to be moved, at step 
1 052. If they are to be delayed, processor 602 sends . 
a command to adaptive synchronization circuit 611 to 
retard subsequentTXJNT_X interrupt signals by the 
amount of time specified in the packet, at step 1054. 
Processor 602 also sends a command to vocoder 604 
to increase the offset of its output clock 622 from clock 
600 signals by the same amount of specified time, at 
step 1 056, and then returns, at step 1 062. If the timing 
signals are to be moved forward in time, processor 
602 sends a command to adaptive synchronization 
circuit 611 to advance subsequent TX_INT_X inter- 
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rupt signals by the amount of time specified in the re- 
ceived signalling packet, at step 1058. Processor 602 
also sends a command to vocoder 604 to decrease 
the offset of its output clock 622 from clock 600 sig- 
nals by the same amount of specified time, at step 5 
1060, and then returns, at step 1062. 

FIG. 20 represents the scenario for initial timing 
adjustments for traffic flow from mobile radio-tele- 
phones 203 to network 100. As was mentioned 
above, mobile radio-telephones 203 and cells 202 are 10 
synchronized with each other. A clock corresponding 
to cell clock 1000 (derived by mobile telephone 203 
from traffic received by it from cell 202) causes a mo- 
bile radio-telephone 203 to make a transmission ev- 
ery 20 msecs. to channel element 245 that is handling 15 
the call, causing channel element 245 to receive 
those transmissions at times 1400 and to convey 
them in packets to SPU 264 at times 1403. Packet 
transmit times 1403 at channel element 245 corre- 
spond to packet receive times 1404 at processor 602 20 
of SPU 264. Receive times 1400 are relatively offset 
from cell clock 1000 by the amount of a programmed, 
constant, offset at cell 202 with respect to transmit 
times 1300. Thus, an offset in transmit times 1300 re- 
sults in a like offset in receive times 1 400. This offset 25 
is compensated for by the mechanisms described 
herein. 

Reception of packets from channel element 245 
for a particular (Xth) service channel 612 is triggered 
at processor 602 by a receive interrupt signal 30 
RX_INT_X for that service channel 612, generated by 
adaptive synchronization circuit 611. Reception of the 
packets must precede by some minimum time the 
transmission of the call traffic frames contained in the 
packets to vocoder 604 1 to give processor 602 suff i- 35 
cient time for processing of the packets. Initially, vo- 
coder 604 expects to receive traffic frames at times 
1408, which correspond to traffic frame transmission 
times 1406 from processor 602. Consequently, in or- 
der to be able to transmit traffic frames to vocoder 604 40 
at rimes 1406, processor 602 must receive corre- 
sponding packets from channel element 245 no later 
than at times ^ 1401. Processor 602 preferably re- 
ceives each packet within a time window 1402, which 
exists a little after transmit time 1406 of the priorframe 45 
transmission to vocoder 604 and a little before time 
t m m 1401 of the present frame transmission. Window 
1402 thus provides some leeway for minor time fluc- 
tuations. 

However when a call is being established, it is un- so 
certain when processor 602 will receive a packet of in- 
formation from channel element 245, for the same 
reasons as it is uncertain when channel element 245 
will receive a packet from processor 602, discussed 
above. Therefore, when a call path is first established 55 
between a channel element 245 and an SPU 264 and 
null traffic begins to how between them, packets from 
channel element 245 may be received by processor 



602 at times 1404 that are outside of windows 1402 
and -in the worst case-- are after times t min 1401. 
Processor 602 cannot change the times 1403 at 
which channel element 245 transmits packets, and 
therefore it cannot change the times 1404 at which it 
receives those packets; processor 602 can only 
change the times 1406 when it transmits frames to vo- 
coder 604. Hence, if times 1404 lie outside of windows 
1402, processor 602 determines a time period 1410 
by which it needs to adjust its time of transmission of 
frames to vocoder 604 in order to position the times 
1404 of its receipt of packets safely within windows 
1402. Processor 602 then commands adaptive syn- 
chronization circuit 611 to adjust the receive interrupt 
signal RX_INT_X for the corresponding service cir- 
cuit 612 by the specified amount. Circuit 611 obliges 
and shifts that receive interrupt signal by the speci- 
fied time period 1410. Frame transmission times from 
processor 602 is vocoder 604 are thus shifted from 
times 1406 to times 1407, which shifts packet receive 
times 1404 at processor 602 inside windows 1402. 

However, in order to be able to shift its frame 
transmit times from times 1406 to times 1407, proc- 
essor 602 must cause vocoder 604 to shift its frame 
receive times from times 1408 to times 1409. Vocoder 
604 uses the output of an internal input clock 621 to 
time its frame receptions. Like output clock 622, input 
clock 621 is synchronized to clock 600 input signals. 
Processor 602 therefore sends a command to vocod- 
er 604 to adjust the offset of its input clock 621 signals 
from the clock 600 input signals by the abovemen- 
tioned time period 1410. Vocoder 604 does so, there- 
by shifting its frame receive times from times 1408 to 
times 1 409. Again, the net result is that the asynchron- 
ous operations of channel element 245 and service 
circuit 612 and processor 602 have been synchron- 
ized with each other. 

The just-described clock adjustment functions 
are performed by processor 602 at step 912 of FIG. 
11, and are shown in FIG. 18. Upon commencing to 
perform the clock adjustment function, at step 1070, 
processor 602 determines from the retrieved call 
state and the received packet type whether the re- 
ceived packet is the first traffic packet for the call, at 
step 1072. If so, processor 602 compares the packet's 
receive time stamp (appended to the packet by LAN 
interface 601) with a window 1402 (the definition of 
which is computed and stored by processor 602 for 
each call that it is handling), at step 1073, to deter- 
mine, at step 1074, when in relation to window 1402 
the packet was received. If the packet was received 
substantially in the center of window 1302, no clock 
adjustment is necessary, and processor 602 pro- 
ceeds to step 1090. If the packet was received too 
early, processor 602 commands adaptive synchroni- 
zation circuit 611 to advance subsequent RX_INT_X 
interrupt signals by the amount of time determined by 
processor 602 to be necessary to move the time of re- 
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ceipt substantially to the center of window 1402, at 
step 1075. Processor 602 also sends a command to 
vocoder 604 to increase the offset of its input clock 
621 from clock 600 signals by the same amount of 
specified time, at step 1076. Conversely, if the packet 
was received too late, processor 602 commands 
adaptive synchronization circuit 611 to retard subse- 
quent RX_INT_X interrupt signals by the amount of 
time determined by processor 602 to be necessary to 
move the time of receipt substantially to the center of 
window 1 402, at step 1 077. Processor 602 also sends 
a command to vocoder 604 to decrease the offset of 
its input clock 621 from clock 600 signals by the same 
amount of specified time, at step 1078. Following step 
1076 or 1078, processor 602 proceeds to step 1090 
(described further below). 

As the call progresses, changes in system traffic 
load, or drift between the master clock to which cells 
202 are synchronized and the master clock to which 
mobile telephone switches 201 are synchronized, 
may cause packet receive times 1306 at channel ele- 
ments 245 to drift out of windows 1302, as illustrative- 
ly shown in FIG. 21, and may cause packet receive 
times 1404 at processor 602 of SPU 264 to drift out 
of windows 1402, as illustratively shown in FIG. 22. 
The drift due to changes in system traffic load will 
tend to be in the same direction with respect to times 
1 306 and 1404: drift that advances time 1 306 with re- 
spect to window 1302 (shown in FIG. 21) will typically 
also advance time 1404 with respect to window 1402 
(not shown), whereas drift that retards time 1 404 with 
respect to window 1402 (shown in FIG. 22) will typi- 
cally also retard time 1306 with respect to window 
1302 (not shown). Conversely, the drift due to asyn- 
chrony between the master clocks will tend to be in 
opposite directions. 

Drifting of times 1306 out of windows 1302 is de- 
tected by the channel element's corresponding clus- 
ter controller 244. Its response thereto is shown in 
FIG. 1 6. Upon receipt of a packet at cluster controller 
244, the route of FIG. 16 is invoked, at step 101, and 
it checks whether the received packet is the first traf- 
fic packet received for the call, at step 1002. Since the 
call is in progress, this will not be the first received 
traffic packet, and the routine continues at step 1014. 
There, the routine compares the time at which the 
packet was received with window 1302, the same as 
at step 1004, to determine, at step 1016, when in re- 
lation to window 1302 the packet was received. If the 
packet was received within window 1 302, no dock ad- 
justment is necessary, and the routine merely returns, 
at step 1022. If the packet was received prior to oc- 
currence of window 1302, the routine causes the next 
traffic packet for this call that is sent to processor 602 
of the SPU 264 that is handling the call to convey in 
its clock adjust field 322 a request to retard the time 
of the TXJNT_X interrupts for this call by one tick 
(e.g., one PCM speech sample time), at step 1018. 



Conversely, if the packet was received after occur- 
rence of window 1 302, the routine causes the next 
traffic packet for this call to convey in its clock adjust 
field 322 a request to processor 602 to advance the 
5 time of the TX_INT_X interrupts for this call by one 
tick, at step 1020. Following step 1018 or 1020. the 
routine returns to the point of its invocation, at step 
1022. 

Upon receipt of the traffic packet, processor 602 

10 proceeds to make the requisite adjustment, at step 
912 of FIG. 11. Drifting of times 1404 out of windows 
1402 is detected by processor 602 itself. Processor 
602 notes the need for adjustment and the direction 
of adjustment, and proceeds to make the requisite ad- 

15 justment tick-by-tick, also at step 912 of FIG. 11 . 

When change in timing of processor 602 activity 
advances packet transmit times 1 305 from times 1 305 
to times 1 505, and hence advances packet receive 
times 1306 with respect to windows 1302, the result 

20 is new packet receive times 1506 which are posi- 
tioned back inside windows 1302, as shown in FIG. 
21. When change in timing of processor 602 activity 
advances windows 1402 and frame transmit times 
1406 with respect to times 1404, the result is new 

25 frame transmit times 1606 and packet receive times 
1404 which are positioned back inside windows 1402, 
as shown in FIG. 22. 

The shift in the TX_INT_X and RXJNT_X signals 
output by circuit 611 requires a corresponding shaft 

30 to be made in the signal outputs of clocks 621 and 622 
of vocoder 604, thereby changing vocoder 604 traffic 
frame transmit times from times 1309 to times 1509 
and changes vocoder 604 traffic frame receive times 
from times 1409 to times 1609 in the example of FIGS. 

35 21 and 22, and thus realigning operations of vocoder 
604 with the time-shifted operations of processor 602. 
At the instant of realignment, however, vocoder 604 
must present a traffic frame of call traffic to processor 
602 after vocoder 604 has had time to collect either 

40 159 or 161 PCM samples from circuit 605 instead of 
the normal 160 samples corresponding to a 20 msec, 
time interval, and must output a frame of call traffic to 
circuit 605 within a time interval of either 159 or 161 
PCM samples instead of the normal 160, depending 

45 upon whether the adjustment is, respectively, to ad- 
vance or to delay the interrupt signals. To compen- 
sate for this condition, when processor 602 com- 
mands circuit 611 to effect the shifts in its TXJNT_X - 
and RX_INT_X signals for this service circuit 612 that 

so are shown in FIGS. 21 and 22, respectively, at the 
same time processor 602 commands vocoder 604 of 
this same service circuit 61 2 to drop one PCM sample 
byte from its PCM output and to create an additional 
one PCM sample byte at its PCM input. Vocoder 604 

55 does so, and the effect is to again align vocoder 604 
traffic frame input and output activities with PCM 
sample output and input activities, respectively. 
In the case of drift opposite to that shown in FIGS. 

18 
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21 and 22, the steps taken to compensate for the drift 
are the inverse of those described for FIGS. 21 and 
22. Specifically, processor 602 commands circuit 601 
to retard its TXJNT_X and RX_INT_X interrupt signal 
outputs for this service circuit 612 by one PCM sam- 
ple interval, and commands vocoder 604 to create an 
additional one PCM sample bye at its PCM output and 
to drop one PCM sample byte from its PCM input. 

These activities of processor 602 are diagramed 
in FIG. 18 at steps 1080 et seq. As was stated previ- 
ously, when processor 602 commences the clock ad- 
justment activities of step 91 2 of FIG. 11 , at step 1070, 
it checks whether the just-received packet is the first 
traffic packet of the call. While the call is in progress, 
a received packet will not be the first received packet, 
and so processor 602 proceeds to step 1080. There, 
processor 602 again compares the received packet's 
time stamp with receive window 1404 in order to de- 
termine, at step 1081, when the packet was received 
in relation to the window. If the packet was received 
within window 1404, no timing adjustment is neces- 
sary, and so processor 602 proceeds to step 1090. If 
the packet was received prior to window 1404, proc- 
essor 602 commands adaptive synchronization circuit 
611 to advance RX_INT_X signal for the correspond- 
ing service circuit 612 by one tick, at step 1082, and 
commands vocoder 604 to decrease the offset of its 
input clock 621 by one tick, at step 1083. Vocoder 604 
does so by causing clock 621 to reset after a count of 
1 59 instead of the usual count of 1 60. But vocoder 604 
still receives a full traffic frame of incoming call traffic 
holding the equivalent of 1 60 PCM sample bytes of in- 
formation. So vocoder 604 discards one of those sam- 
ple bytes to mask the timing realignment at its PCM 
output. 

Returning to step 1081, if the packet is found to 
have been received after window 1404, processor 
602 commands adaptive synchronization circuit 611 
to retard RX_INT_X signal for the corresponding ser- 
vice circuit 612 by one tick, at step 1084, and com- 
mands vocoder 604 to increase the offset of its input 
clock 621 by one tick, at step 1085. Vocoder 604 does 
so by causing clock 621 to reset after a count of 161 
instead of the usual count of 1 60. But vocoder 604 still 
receives a traffic frame of incoming traffic holding the 
equivalent of 160 PCM sample bytes of information. 
So vocoder 604 generates an additional sample bye 
to mask the timing realignment at its PCM output. 

Following steps 1083 or 1085, processor 602 pro- 
ceeds to step 1090. There, processor 602 examines 
clock adjust field 322 of the received traffic frame to 
determine what clock adjustment, if any, has been re- 
quested by cell 202 that is handling the call. If an ad- 
justment has been requested, processor 602 com- 
mands adaptive synchronization circuit 611 to adjust 
the time of occurrence of the TX_INT_X interrupts for 
the call's corresponding service circuit 61 2 by one tick 
in the requested direction, at step 1091, and com- 



mands vocoder 604 to adjust the offset of its output 
clock 621 by one tick in the same direction, at step 
1092. Vocoder 604 does so by causing clock 621 to 
reset after a count of 159 or 161 instead of the usual 

5 count of 160. Consequently, vocoder 604 accumu- 
lates either 159 or 161 PCM bytes of outgoing traffic 
samples to supply to processor 602 in a frame holding 
160 PCM sample bytes. To mask the timing realign- 
ment at its output to processor 602, vocoder 602 ere- 

w ates an additional PCM sample in the first instance 
and discards one of the PCM samples in the second 
instance. Following step 1092, clock adjustment ac- 
tivities are completed, and processor 602 returns, at 
step 1093, to the call processing activities of FIG. 1 1 . 

15 Alternatively, clocking adjustments may be made 

in multiples of one 125 usee, ticks in order to achieve 
synchronization at a faster rate. Also, a combination 
of multiple-tick and single-tick adjustments (in differ- 
ent 20 msec, cycles) could be used in order to control 

20 the speed with which synchronization may be ach- 
ieved. Further, coarse adjustments (i.e., involving 
multiple 125 usee, ticks) may be made in order to 
make major synchronization changes during a call. 
Said large adjustments are advantageously made 

25 during the periods when speech activity is low. 

At the start of a soft handoff, a channel element 
245 of a second cell 202 commences to handle the 
call in parallel with channel element 245 of a cell 202 
that has been handing the call alone until now. It is not 

30 known a prior whether packet receive times 1306 at 
the second channel element 245 will fall inside or out- 
side of windows 1 302 (see FIG. 1 9) or whether packet 
receive times 1404 of packets sent by second channel 
element 245 will fall inside or outside of windows 1402 

35 (see FIG. 20) at processor 602, just as when the call 
is initially established. If receive times 1 306 and 1404 
do fall outside of windows 1 302 and 1 402, respective- 
ly, for the second channel element 245, however, the 
clock adjustment technique of FIGS. 1 9 and 20 which 

40 was used when the call was initially established, can- 
not now be used. This is because the call is now an 
established and ongoing call, and the use of that tech- 
nique would result in noticeable disruption —.an audi- 
ble "glitch" - in the call. Consequently, the more grad- 

45 ual but effectively "glitch -I ess" clock adjustment tech- 
nique of FIGS. 21 and 22 is used to try and move re- 
ceive times 1306 and 1404 within windows 1302 and 
1402, respectively, for the second channel element 
245. Multiple iterations of this adjustment may need to 

so be performed in order to achieve the desired effect. 

It is important to note, however, that the adjust- 
ment of FIGS. 21 and 22 affects the receive times 
1306 and 1404 for both of the channel elements 245 
that are handling the call. Consequently, it is possible 

55 that an adjustment which attempts to move times 
1306 and 1404 into windows 1302 and 1402 for the 
second channel element 245 will result in moving 
times 1306 and 1404 out of windows 1302 and 1402 

19 
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for the first channel element 245. 

It is imperative that times 1306 and 1404 of nei- 
ther of the two channel elements 245 lag (i.e. occur af- 
ter) their respective windows 1302 and 1402. In con- 
trast, times 1 306 and 1404 that lead (i.e. occur before) 
their respective windows 1302 and 1402 can be com- 
pensated for by buffering of the prematurely-received 
packets at channel element 245 and SPU 264. Con- 
sequently, if during soft handoff one channel element 
245 is reporting a leading time 1306 while the other 
channel element 245 is reporting a lagging time 1306, 
the clock adjustment requests of the channel element 
245 which is reporting leading times 1306 are ignored 
and only the requests of the other channel element 
245 which is reporting lagging times 1306 are re- 
sponded to by processor 602. 

It is conceivable that differences in propagation 
delays between processor 602 and the two channel 
elements 245 that are involved in the soft handoff are 
so great that packets sent by both channel elements 
245 during the same clock cycle of cell clock 1 000 are 
received at processor 602 during different clock cy- 
cles of processor 602 receive interrupt clock 
RX_INT_X for that channel element 6 12, and that du- 
plicate packets sent by processor 602 during the 
same dock cycle of transmit interrupt clock 
TX_INT_X to both channel elements 245 involved in 
the soft handoff are received by those channel ele- 
ments 245 during different clock cycles of cell clock 
1000. To associate the received packets with the 
proper clock cycles is the purpose of the sequence 
numbers coded by sequence number field 320 of traf- 
fic frames 350 (see FIG. 9). The association is done 
at steps 932-936 of FIG. 11. 

As was alluded to previously, sequence numbers 
used by channel elements 245 are calculated from, 
and hence bear a detailed relationship to, clock cycles 
of cell clock 1000. Hence, during any clock cycle of 
cell clock 1000, all channel elements 245 transmit 
packets having the same sequence number. Conse- 
quently, by comparing the sequence numbers of two 
received packets, processor 602 can immediately de- 
termine whether both packets correspond to the 
same clock cycle of clock 1000. and if they do not, 
what their relative sequence is. 

In the opposite direction of packet flow, from proc- 
essor 602 to channel elements 245, no defined rela- 
tionship exists between sequence number and clock 
cycle of cell clock 1000. However, at the beginning of 
the soft handoff, the channel element 245 that has 
been handling the call until now causes a message 
(HANDOFF_REG; see discussion of FIG. 27, below) 
to be sent to the channel element 245 that is now com- 
mencing to handle the call, which message reports 
the number of a recent cell clock 1 000 dock cycle and 
the sequence number of a packet which the first chan- 
nel element 245 has received dig that clock cycle. 
Since sequence numbers are sequential, the second 



channel element 245 can easily compute from this re- 
ceived information which sequence numbers are as- 
sociated with which subsequent clock cycles of cell 
clock 1 000. The second channel element 245 thus de- 

5 termines the cell clock 1 000 clock cycle to which a re- 
ceived packet corresponds. 

It will now be explained in conjunction with FIGS. 
23-35 how calls are set up, handed off, and torn down 
in the system of FIG. 2. The illustrated activities take 

10 place as a result of exchanges of level-3 packetized 
signalling messages, illustratively between pairs of 
elements, e.g., SPU 264 to cells 202, cell 202 to ECP 
complex 134, or ECP complex 134 to DCS controller 
261. The Figures imply timing relationships for mes- 

15 sage exchanges between the element pairs only, and 
not across element pairs. All messages to and from 
ECP complex 1 34 are assumed to flow through con- 
trol links 108; all packets between channel elements 
245 and service circuits 612 are assumed to be 

20 frame-relayed through trunks 207 and 210. 

FIG. 23 shows control signalling for setting up a 
packet-switched call path for a call originating at a mo- 
bile telephone 203. Mobile telephone 203 initiates the 
call by transmitting an ORIGINATION signal (illustra- 

25 tively one or more digital messages) conveying the 
called telephone number on an access channel. 
Over-the-air transmission or reception of signals is in- 
dicated in the Figures by a vertical segment of a signal 
arrow. The ORIGINATION signal is received by chan- 

30 nel element 245 designated as a CDMA access chan- 
nel in one of the cells 202, which passes it on in a mes- 
sage to its cluster controller 244, which forwards it to 
controller 241 of its cell 202. Each controller 241 as- 
signs a free CDMAair channel to cry the call, and then 

35 passes the message along with identity of the as- 
signed channel's corresponding channel elements 
245 on to ECP complex 134, in a conventional man- 
ner. 

ECP complex 134 receives the CELL_ORIGINA- 
40 TION message and selects a DCS 201 , a CIM 209, an 
SCM 220, and a service circuit 612 and a setup of 
trunks 106 of the selected speech coder module 220, 
to handle the call. ECP complex 134 then sends an 
MSC_FS_ASSIGNMENT message to controller 241 
45 of the call-originating cell 202, conveying a DLCI of 
the selected service circuit 612. ECP complex 134 
also sends a SETUP message conveying the called 
telephone number and identifying selected module . 
220, groups of trunks 1 06, and service circuit 612, to 
so DCS controller 261 that controls the selected module 
220. 

Controller 241 that receives the MSC_FS_AS- 
SIGNMENT message forwards the message to clus- 
ter controller 244 of selected channel element 245. 
55 Cluster controller 244 conveys the information includ- 
ed in the message to channel element 245 that has 
been selected to handle the call. Selected channel 
element 245 sets itself up to handle the call and then 

20 
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sends an FS_CONNECT packet 351 to the selected 
service circuit 61 2, using the frame-relay technique to 
transport the packet through the interconnecting fa- 
cilities' channels. Packet 351 uses the received DLCI 
of the selected service circuit 612 as the packet ad- 5 
dress in field 302, and conveys the DLCI of the select- 
ed channel element 245 in its data field 304. 

When processor 602 serving the selected ser- 
vice circuit 612 receives the FS_CONNECT packet, it 
returns an FS_ACK packet 351 to selected channel 10 
element 245 in acknowledgment of receipt of the 
FS_CONNECT packet, using the DLCI contained in 
field 304 of the FS_CONNECT packet as the packet 
address in field 302 of the FS_ACK packet. Illustra- 
tively at this time processor 602 also sends to cell 202 15 
all DLCIs that correspond to selected service circuit 
612. Processor 602 performs these tasks as part of 
LAPD processing at step 904 of FIG. 11. Processor 
602 then stores the conveyed DLCI of selected chan- 
nel element 245 as part of the call state that is asso- 20 
ciated with selected service circuit 612, and marks 
the call state as corresponding to an active call. Acon- 
nection is now established between selected channel 
element 245 and service circuit 612. Cluster controller 
244 of the selected channel elements 245 next re- 25 
sponds with an FS_CLOCK_ADJUST pucket in which 
it conveys to processor 602 serving the selected serv- 
ing circuit the initial clock- adjustment information. 
This packet was discussed in conjunction with FIG. 
16, steps 1001-1010. Processor 602 responds, by re- 30 
turning an FS_ACK packets to cluster controller 244 
and processing the received packet in the manner dis- 
cussed in conjunction with FIG. 17. A call path is now 
established between channel element 245 and ser- 
vice circuit 612, and they begin to exchange null traf- 35 
f ic packets every 20 msecs. until call traffic becomes 
available. Selected channel element 245 responds to 
receipt of the second FS_ACK packet by causing a 
CHANNEL_CONFIRMATION message to be sent by 
its cell's controller 241 to ECP complex 134 to advise 40 
it of completion of this end of the connection. 

DCS controller 261 that receives the SETUP 
message responds by causing controller 231 of the 
selected SCM 220 to seize a trunk 1 06 (DS0 channel) 
of the identified groups of trunks 1 06 and to outpulse 45 
the called telephone number on the seized trunk 106. 
The selected trunk 106 corresponds to a particular 
time slot on TDM bus 130. Controller 261 also causes 
translation and maintenance processor 609 of speech 
processing unit 264 which contains the selected ser- so 
vice circuit 612 to connect the abovementioned DS0 
channel from TDM bus 1 30 via TDM bus interface 608 
to that time slot of concentration highway 607 which 
is assigned to selected service circuit 612, thereby 
assigning that service circuit 612 to handle the sub- 55 
ject call. Controller 261 then sends a CONNACK mes- 
sage to ECP complex 134 to advise it of successful 
completion of this end of the connection. When an- 



swer supervision is received from telecommunica- 
tions facilities of network 10 over the selected trunk 
106 by controller 231, it notifies DCS controller 261, 
which in turn sends an ANSWER message to ECP 
complex 1 34 to notify it of call completion. The call is 
now established fully through the system of FIG. 2, 
and call traffic can flow between selected channel 
elements 245 through service circuit 612 and trunk 
106 to and from the telecommunications facilities of 
network 100 and the call's destination. 

FIG. 24 shows control signalling for setup of a call 
path for a call originating at public telephone network 
100. Network 100 initiates the call by seizing a trunk 
106 and outpulsing thereon the digits of the called tel- 
ephone number, in a conventional manner. Controller 
231 of a speech coder module 220 serving that trunk 
106 detects the seizure on the trunk's corresponding 
time slot of TDM bus 1 30 and collects the dialed digits, 
again conventionally, and then notifies DCS controller 
261. Controller 261 in turn notifies ECP complex 134 
by sending it an INCALL message. The INC ALL mes- 
sage conveys the called telephone number, and mod- 
ule 220 and trunk 106 I.D.s. 

ECP complex 134 responds to the INCALL mes- 
sage by broadcasting to all cells 202 in the system of 
FIG. 2 an MSC_PAGE_REQUEST message. The 
MSC_PAGE_REQUEST message identifies the cod- 
ed mobile 203 (e.g., conveys the coded phone num- 
ber). 

Controller 142 of each cell 202 responds to the 
MSC_PAGE_REQUEST message by conveying the 
MSC_PAGE_REQUEST message to a CDMA ac- 
cess-channel element 245 via cluster controller 244. 
The access-channel element 245 responds by paging 
the called mobile 203, in the manner specified for the 
CDMA arrangement. 

When the called mobile 203 responds by transmit- 
ting a RESPONSE signal, one or more of the paging 
channel elements 245 receive the signal, and each 
passes iton to its respective cluster controller 244. Clus- 
ter controllers 244 forward the messages to controllers 
241 of their respective cells 202. Controllers 241 of all 
cells 202 are continually exchanging messages (not 
shown) to update each other's databases of their re- 
spective status for existing and pending calls. Control- 
lers 241 of the respective cells 202 determine from these 
messages which cell 202 is bestsuited to handle the call. 
Controller 241 of the selected cell 202 then sends a 
CELL_PAGE_RESPONSE message on to ECP com- 
plex 134 to notify complex 134 of that cell's selection 
to handle the call. 

ECP complex 134 receives the CELL_PAGE_ 
RESPONSE message and selects a service circuit 
612 of module 220 to which the call is connected to 
handle the call at the other end of the call path. ECP 
complex 1 34 then sends an MSC_FS_ASS!GNMENT 
message to controller 241 of the selected cell 202. 
The message is the same as described for the mobile 
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call-origination, and elicits the same response - to 
wit, an FS_CONNECT, FS_ACK, FS_CLOCK_AD- 
JUST, and FS_ACK packet exchange sequence be- 
tween cell 202 and SPU 264, followed by a CHAN- 
NEL_CONFIRMATION message from cell 202 to ECP 
complex 1 34, as described for FIG. 23. ECP complex 
1 34 also sends a TONE_REQ message to DCS con- 
troller 261 that controls the module 220 to which the 
call is connected. Controller 261 responds by causing 
controller 231 of module 220 to apply ringback to the 
trunk 106 that carries the call to and from telecommu- 
nications facilities of network 100. 

Following sending of CHAN NE ^CONFIRMA- 
TION message to ECP complex 134, selected chan- 
nel element 245 transmits RINGING signals to called 
mobile 203. When called mobile 203 responds with an 
ANSWER signal, selected channel element 245 caus- 
es an ANSWER message to be conveyed from its 
cell's controller 241 to ECP complex 134. ECP com- 
plex 134 responds by sending an ACCEPT message 
to DCS controller 261 of module 220 to which the call 
is connected. The message conveys the I.D. of ser- 
vice circuit 612 that had been selected to handle the 
call. Controller 261 responds by causing controller 
231 to remove ringback tones from the call, and then 
causing a connection to be made between the DS0 
channel carrying the call on TDM bus 130 and select- 
ed service circuit 612, in the manner described for a 
mobile-originated call. Controller 261 then sends a 
CONNACK message to ECP complex 134 to advise 
it of successful completion of this end of the connec- 
tion. The call path is now established fully through the 
system of FIG. 2, and packets being call traffic can 
flow between selected channel element 245 and the 
call's source, through service circuit 612. 

FIG. 25 shows control signalling for call discon- 
nection initiated by mobile telephone 203. Mobile tel- 
ephone 203 initiates disconnection of an established 
call in which it is participating by transmitting a HANG- 
UP signal. This signal is received by channel element 
245 which is handling the call. Channel element 245 
responds by sending an FS_REMOVE packet 351 to 
service circuit 612 which is handling the call, to advise 
it of the call disconnection. 

Processor 602 responds to the FS_REMOVE 
packet by returning an FS_ACK packet 351 to chan- 
nel element 245 as part of the protocol processing of 
the FS_REMOVE packet, and by updating the call 
state for the service circuit 612 which is handling the 
call to show that the call has been disconnected. Traf- 
fic for the call now ceases to flow between channel 
element 245 and service circuit 612, and channel ele- 
ment 245 causes as RELEASE_MSC message to be 
sent by its cell's controller 241 to ECP complex 134, 
to advise it of disconnection of this end of the call path. 

ECP complex 134 responds by sending a CLEAR 
message to DCS controller 261 of speech coder mod- 
ule 220 that is handling the call, and by sending an 



MSC_RELEASE_ACK message to controller 241 of 
cell 202 that was handling the call, to advise it that 
channel element 245 which had been handling the 
call is now free and available to handle a new call. 

5 Controller 261 responds to the CLEAR message by 
causing controller 231 of module 220 to release trunk 
106 that carries the call, and causing translation and 
maintenance processor 609 of the speech processing 
unit 264 that contains service circuit 612 which is han- 

10 dling the call to disconnect the DS0 channel which is 
carrying the call from the concentration highway 607 
time slot that is assigned to that service circuit 612. 
Controller 261 then sends a CLEAR_ACK message to 
ECP complex 105 to notify it that this end of the call 

15 path has also been disconnected. 

FIG. 26 shows control signalling for call discon- 
nection initiated from public telephone network 100. 
Network 100 releases trunk 106 which carries the 
call. The release is detected by controller 231 of 

20 speech coder module 220 that is handling the call, 
which notifies DCS controller 261, and controller 261 
in turn notifies ECP complex 134 by sending it a DIS- 
CONNECT message. 

ECP complex 134 responds to receipt of the DIS- 

25 CONNECT message by sending an MSC_NET- 
WO RK_RE LEAS E message through cell controller 
241 and cluster controller 244 to channel element 245 
that is handling the call. Channel element 245 re- 
sponds by transmitting a RELEASE signal to mobile 

30 telephone 203 that is involved in the call, and causing 
an FS_REMOVE packet 351 to be sent to service cir- 
cuit 612 that is handling the call. The FS_REMOVE 
signal is the same as described for the mobile-initiat- 
ed disconnection, and elicits the same response. 

35 In response to receiving the RELEASE signal, 

mobile telephone 203 hangs up the call and transmits 
a HANGUP signal. This signal is received by channel 
element 245 that is handling the call, and it responds 
by causing a RELEASE_CONFIRMATION message 

40 to be sent by its cell's controller 241 to ECP complex 
134, to inform it of disconnection of this end of the call. 

ECP complex 1 34 responds by sending a CLEAR 
message to DCS controller 261 of speech coder mod- 
ule 220 that has been handling the call. The CLEAR 

45 message is the same as described for the mobile-ini- 
tiated termination, and elicits the same response. 

FIGS. 27-29 show control signalling for soft hand- 
off of the call from one cell 202 to another. FIG. 27 
shows signalling for the beginning of soft handoff, 

so when a second cell 202, referred to as a slave cell, 
commences to handle the call jointly with cell 202 that 
had been handling the call until then, referred to as a 
master cell. A mobile telephone 203 that is involved in 
a call monitors the strength of pilot channel signals 

55 that it receives from a plurality of cells 202 including 
master cell 202, and it periodically sends to master 
cell 202 a PWR.INFO. report on these received power 
levels. Channel element 245 that is handling the call 

22 
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passes this report on to controller 241 of master cell 
202. On the basis of this information, and information 
exchanged between the cells 202 themselves, con- 
troller 241 of master cell 202 determines whether only 
master cell 202 should continue to handle the call, or 5 
whether another cell 202 should be added to the call. 
If controller 141 of master cell 202 determines that an- 
other cell 202 should be added to the call, and that this 
slave cell 202 can handle the call using CDMA and the 
same mobile channel as master cell 202, controller 10 
241 of master cell 202 sends a HANDOFF_REQ mes- 
sage through control links 1 08 and IMS 1 04 to control- 
ler 241 of slave cell 202. HANDOFF_REQ message 
conveys theDLCIs of call-handling service circuit 61 2 
which are not used by master cell 202 for this call, and 15 
the I.D. of the mobile channel on which the call is be- 
ing conducted. 

Controller 241 of slave cell 202 receives the 
HANDOFF_REQ message and selects a channel ele- 
ment 245 of slave cell 202 and one of the received 20 
DLCIs of call-handling circuit 612 to handle the call. 
(Alternatively, the HANDOFF_REQ message may 
convey the DLCI of call-handling service circuit 612 
which is used by master cell 202 for this call, and con- 
troller 241 of slave cell 202 merely toggles the value of 25 
the least-significant bit of that DLCI which is contained 
in the message, to change the DLCI value to a second 
DLCI that corresponds with service circuit 612 that is 
handling the call.) Controller 241 then forwards the se- 
lected DLCI along with other contents of the received 30 
message through a cluster controller 244 to selected 
channel element 245. Selected channel element 245 
sets itself up to handle the call on the specified mobile 
channel, and then causes an FS_JOIN packet 351 to be 
sent to service circuit 612 that is handling the call. 35 
This packet uses the DLCI of service circuit 612 which 
was received by selected channel element 245 from 
controller 241 as the packet address in field 302, and 
conveys the DLCI of selected channel element 245 in 
its data field 304. 40 

When processor 602 serving service circuit 612 
that is handling the call receives the FS_JOIN packet, it 
returns an FS_ACK packet 351 to selected channel ele- 
ment 245 in acknowledgment of receipt of the FS_JOIN 
packet as part of LAPD processing at step 904 of 45 
FIG. 11. Processor 602 then stores the conveyed 
DLCI of selected channel element 245 as part of the 
call state that is associated with service circuit 612 
that is handling die call, and marks the call state as 
being in soft handof f. A connection is now established so 
between selected channel element 245 of slave cell 
202 and service circuit 612 that is handling the call, 
and they begin to exchange call traffic packets. 

Channel element 245 of slave cell 202 responds 
to receipt of the FS_ACK packet by causing a HAND- 55 
OFF_ACK message to be sent by its cell's controller 
241 via control links 108 and IMS 104 to controller 241 
of master cell 202 to advise it of completion of the con- 



nection. Controller 241 of slave cell 202 also sends a 
HANDOFFJN FORMATION message to ECP com- 
plex 1 34 to notify it of the soft handof f, and ECP com- 
plex 134 updates its database. Call traffic packets 
now how between the one service circuit 612 and 
channel elements 245 of both master and slave cells 
202 that are handling the call. 

FIGS. 28 and 29 show signalling for the end of 
soft handof f, when one of the two cells 202 that is han- 
dling the call ceases to do so. Typically, though not 
necessarily, this will be the master cell 202. This sce- 
nario is shown in FIG. 28. During soft handoff, master 
and slave cells 202 receive PWR.INFO. reports on pi- 
lot channel power levels measured by mobile tele- 
phone 203. Note that this PWR.INFO. is different from 
the power control trend information which is received 
during soft handoff from both cells 202 by processor 
602 and is swapped between the two cells 202. Each 
cell 202 includes the received PWR.INFO. as reverse 
signalling in the next packet 350 that it sends to ser- 
vice circuit 612 that is handling the call. 

Processor 602 serving service circuit 612 that is 
handling the call receives the PWR.INFO. as reverse 
signalling from both cells 202, selects and saves the 
PWR.INFO. from only one cell 202, at steps 968 of 
FIG. 1 3 or 998 of FIG. 14, and then sends the stored 
PWR.INFO. back to both ceils 202, at steps 121 6 and 
1 236 of FIG. 1 5. On account of the actions performed 
by processor 602, each cell 202 that is involved in the 
handoff receives PWR.INFO. sent by the cell 202 that 
received better quality signals from mobile 203. The 
received PWR.INFO. is forwarded to the receiving 
cells' controllers 241. 

Controllers 241 use this information to determine 
when one of them should cease handling the call. 
When controller 241 of master cell 202 determines 
that is should cease handling the call, it sends a 
HANDOFF_DIRECTION signalling packet to proces- 
sor 602 that serves the call-handling service circuit 
612. The packet indicates that handling of the call is 
being turned over to slave cell 202. Processor 602 du- 
plicates the signalling and returns it to both master 
and slave cells 202, as shown in FIG. 15. 

Upon receiving the HAN DOFF_DIRECTION sig- 
nalling, channel elements 245 of both master and 
slave cells 202 transit the HANDOFF_DIRECTION in- 
formation to mobile telephone 203 to appraise it 
thereof. Controller 241 of master cell 202 then sends 
a MASTER_TRANSFER message via control links 
108 and IMS 104 to controller241 of the other cell 202 
that is involved in the soft handoff, to notify it of com- 
pletion of the handoff and that it is to become the new 
master cell 202, and also forwards a copy of that in- 
formation to channel element 245 of its own cell 202 
which is handling the call. Channel element 245 re- 
sponds by ceasing to communicate call traffic to and 
from mobile telephone 203 and causing an FSJRE- 
MOVE packet to be sent to service circuit 612 that is 
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handling the call to advise it of cessation of its involve- 
ment in the call. 

Processor 602 responds to the FS_REMOVE 
packet by returning an FS_ACK packet to sending 
channel element 245 as part of the protocol process- 
ing of the FS_REMOVE packet, and by updating the 
call state for service circuit 612 to show that the call 
is no longer in soft handoff. Controller 241 of former 
master cell 202 receives the FS_ACK packet and re- 
sponds by ceasing its cell's involvement in the call. 
Traffic for the call ceases to flow between channel 
element 245 of former master cell 202 and service cir- 
cuit 61 2 that is handling the call, but continues to flow 
between service circuit 612 and channel element 245 
of the former slave cell 202. Controller 241 of former 
master cell 202 now sends a H AN DO FFJN FORMA- 
TION message to ECP complex 134 to notify it of 
completion of the handoff and the result thereof. ECP 
complex 1 34 updates its database accordingly. 

It will be noted that DCS controller 261 of the 
serving DCS 201 remains wholly uninvolved in the 
procedures of FIGS. 27 and 28, and that ECP com- 
plex 134 is also uninvolved except for being notified 
of the completions of the procedures. Consequently, 
the call-handling capacity of DCS controller 261 and 
ECP complex 134 is not adversely impacted by the 
soft-handoff procedures. 

FIG. 29 shows the scenario for soft-handoff com- 
pletion wherein slave cell 202 ceases to serve the call 
202 and master cell 202 continues to serve the call 
alone. Once again, the procedure begins with the 
master and slave cells 202 providing pilot channel 
PWR.INFO. reports to processor 602 that serves the 
call-handling service circuit 612, and return to both 
cells 202 of the PWR.INFO. that was provided by the 
cell 202 that is receiving better signals from mobile tel- 
ephone 203. When controller 241 of master cell 202 
determines on the basis of these and other reports 
that slave cell 202 should cease handling the call, it 
sends a HANDOFF_DIRECTION signalling packet to 
processor 602 which indicates that handling of the call 
is being regained by master cell 202. Processor 602 
duplicates the signalling and returns it to both master 
and slave cells 202, again as shown in FIG. 15. 

Upon receiving the HANDOFF_DI RECTION sig- 
nalling, channel elements 245 of both master and 
slave cells 202 transmit the HANDOFF-DIRECTION 
information to mobile telephone 203 to appraise it 
thereof. Controller 241 of master cell 202 then sends 
an INTRA/INTER_CELL HANDOFF_REMOVE mes- 
sage via control links 108 and IMS 104 to controller 
241 of slave cell 202 to notify it of completion of the 
handoff and that it is to drop out of handling of the call. 
Controller 241 of slave cell 202 notifies channel ele- 
ment 245 of slave cell 202 which is handling the call. 
Channel element 245 responds in the same manner 
as was described in conjunction with FIG. 28 for chan- 
nel element 245 of master cell 202: by ceasing to com- 



municate call traffic to and from mobile telephone 203 
and initiating an FSJREMOVE, FS_ACK packet ex- 
change with processor 602. Traffic flow ceases be- 
tween channel element 245 of slave cell 202 and ser- 

5 vice circuit 612 that is handling the call, but continues 
between service circuit 612 and channel element 245 
of master cell 202. Controller 241 of former slave cell 
202 now sends a INTRA/INTER_CELL_HAND- 
OFF_ACK message to master cell 202, and a HAND- 

10 OFF_JN FORMATION message to ECP complex 1 34, 
to notify them of completion of the handoff and there- 
suit thereof. ECP complex 134 updates its database 
accordingly. 

As in FIG. 28, there is little or no involvement of 

15 DCS controller 261 and ECP complex 134 in this 
handoff-terrnination procedure. 

FIG. 30 shows control signalling for call discon- 
nection initiated by mobile telephone 203 while the 
call is in soft handoff. Mobile telephone 203 initiates 

20 disconnection of the call by transmitting a RELEASE 
signal. This signal is received by channel elements 
245 which are handling the call in both master and 
slave cells 202. Each channel element 245 responds 
by sending cell-to-mobile reverse signalling convey- 

25 ing the RELEASE signal in the next packet 350 that it 
sends to service circuit 612 that is handling the call. 

Processor 602 serving that service circuit 612 re- 
ceives the signalling from both cells 202 but saves 
only one copy, at step 968 of FIG. 13 or 998 of FIG. 

30 14, and returns the saved copy of the RELEASE sig- 
nalling back to channel elements 245 of both master 
and slave cells 202 in the next traffic packet, at steps 
1216 or 1222 and 1236 of FIG. 15. Controller 241 of 
master cell 202 responds to return of the RELEASE 

35 signalling by sending cell-to-mobile MOBILE_DIS- 
CONNECT forward signalling in the next packet 350 
that is sent to service circuit 612 that is handling the 
call. 

Processor 602 serving that service circuit 61 2 re- 

40 ceives and stores the signalling, at step 956 of FIG. 
1 3 or step 986 of FIG. 14, and then returns it to chan- 
nel elements 245 of both master and slave cells 202 
in the next traffic packet, at steps 1222 and 1236 of 
FIG. 15. Channel elements 245 of both master and 

45 slave cells 202 each respond to receipt of the MO- 
BILEJDISCONNECT signalling by transmitting a RE- 
LEASE signal to mobile telephone 203. Controller 241 
of master cell 202 then sends a cell-to-mobile signal- , 
ling NULL_TRAFFIC command in the next packet to 

so service circuit 612. This command is returned to both 
cells 202 by processor 602, in the manner just descri- 
bed for MOBILE_DISCONNECT signalling. Channel 
elements 245 of both master and slave cells 202 each 
respond to receipt of the NULL_TRAFFIC command 

55 by ceasing to transmit call traffic and instead com- 
mencing to transit null traffic to mobile telephone 203. 
Both channel elements 245 also each cause an 
FS_REMOVE packet 351 to be sent to service circuit 

24 
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612 that is handling the call. The packets are the same 
as has been described previously, and elicit the same 
responses from processor 602. Upon receipt of an 
FS_ACK packet from processor 602, each cell's 
channel element 245 stops communicating with mo- 
bile telephone 203, and causes a RELEASE_MSC 
message to be sent by its cell's controller 241 to ECP 
complex 134 to notify complex 134 that the corre- 
sponding cell 202 has ceased to handle the call. ECP 
complex 134 updates its database correspondingly, 
and sends MSC_RELEASE_ACK messages to con- 
trollers 241 of master and slave cells 202. Following 
receipt of the second RELEASE JvISC message, ECP 
complex 134 also sends a CLEAR message to DCS 
controller 261 of speech coder module 220 that is han- 
dling the call. The message is the same as described 
for FIG. 25 and elicits the same response from DCS 
controller 261. 

FIG. 31 shows control signalling for call discon- 
nection initiated from public telephone network 100 
while the call is in soft handoff. Network 1 00 releases 
trunk 106 that carries the call. The release is detected 
by controller 231 of speech coder module 220 that is 
handling the call, and controller 231 nodes DCS con- 
troller 261, which in turn nodes ECP complex 134 by 
sending it a DISCONNECT message. 

ECP complex 134 responds by sending an 
M SC_N ETWO RK_RE LEAS E message to cell con- 
trollers 241 of master and slave cells 202. Controller 
241 of master cell 202 responds by sending cell-to- 
mobile forward signalling conveying a RELEASE sig- 
nal in the next packet 350 that it sends to service cir- 
cuit 612 that is handling the call. 

Processor 602 serving that service circuit 61 2 re- 
ceives the RELEASE signal and stores it, at step 956 
of FIG. 13 or step 986 of FIG. 14, and then sends the 
stored RELEASE signal to channel elements 245 of 
both master and slave cells 202 in the next traffic 
packet, at steps 1222 and 1236 of FIG. 15. Channel 
elements 245 of both master and slave cells 202 each 
respond to the signalling information by transmitting 
a RELEASE signal to mobile telephone 203 that is in- 
volved in the call. 

In response to receiving the RELEASE signals 
transmitted by channel elements 245, mobile tele- 
phone 203 hangs up the call and transmits a MOBILE 
DISCONNECT signal as confirmation. This signal is 
received by channel elements 245 of both master and 
slave cells 202. Each channel element 245 that is 
handling the call responds thereto by causing a 
FS_REMOVE packet 351 to be sent to service circuit 
612 that is handling the call. The packets are the same 
as has been described previously, and elicit the same 
responses from processor 602. Upon receipt of the 
FS_ACK packet from processor 602, each channel 
element 245 responds by causing a RELEASE_CON- 
FIRMATION message to be sent to ECP complex 134 
to inform it of the call disconnection. 



Following receipt of the second RELEASE_CON- 
FIRMATION message, ECP complex 134 sends a 
CLEAR message to DCS controller 261 of speech 
coder module 220 that is handling the call. The mes- 

5 sage is the same as described for FIG. 25 and elicits 
the same response. 

FIG. 32 shows control signalling for a semi-soft 
handoff of the call from one channel element 245 to 
another. A semi-soft handoff occurs between channel 

10 elements 245 of either the same cell 202 or different 
cells 202 connected to the same DCS 201, and in- 
volves a change in the mobile channel that is carrying 
the call. As for soft handoff, controller 241 of cell 202 
that is handling the call -- the serving cell monitors 

15 PWR.INFO. supplied by mobile telephone 203 to de- 
termine whether serving channel element 245 should 
continue to do so, or whether the call should be hand- 
ed off to a new channel element 245 in either the 
same or a different « a new cell 202. If controller 

20 241 of serving cell 202 determines that it should hand 
off the call to a new channel element 245, and that 
new cell 202 can handle the call using CDMA, control- 
ler 241 of serving cell 202 sends a HANDOFF_REQ 
message through control links 108 and IMS 104 to 

25 controller 241 of new cell 202. (If serving cell 202 and 
new cell 202 are the same cell, this message is not 
sent outside of the cell.) The message is the same as 
design for soft handoff, and elicits the same response 
from new cell 202 as it does from a slave cell 202. 

30 However, because new channel element 245 does 
not operate on the same mobile channel as mobile tel- 
ephone 203 and serving channel element 245, new 
channel element 245 is not in communication with mo- 
bile telephone 203 and only null traffic packets how 

35 from new channel element 245 to service circuit 612 
that is handling the call. 

The HANDOFF_ACK message that is sent by 
new cell 202 back to serving cell 202 specifies the 
mobile channel on which new channel element 245 

40 operates. Controller 241 of serving cell 202 receives 
the HANDOFF_ACK message and responds thereto 
by causing serving channel element 245 to transmit 
a signal to mobile telephone 203 telling it to switch its 
operations to the mobile channel on which new chan- 

45 nel element 245 operates. When mobile telephone 
203 does so. traffic begins to flow between mobile tel- 
ephone 203, new channel element 245, and service 
circuit 612, but ceases to flow between mobile tele- 
phone 203 and serving channel element 245, and 

50 only null traffic packets commence to flow from serv- 
ing channel element 245 to service circuit 612. 

New channel element 245 responds to com- 
mencement of receipt of call traffic from mobile tele- 
phone 203 by causing a HANDOFFJNFORMATION 

55 message to be sent to ECP complex 1 34, and an IN- 
TERCELL_HANDOFF message to be sent to serving 
cell 202, to notify them of the handoff. ECP complex 
134 updates its database, while controller 241 of 

25 
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serving cell 202 causes the cell to drop out of serving 
the call. Specifically, channel element 245 of serving 
cell 202 causes an FS_REMOVE packet to be sent to 
service circuit 612 that is serving the call. The packet 
is the same as discussed previously and elicits the 5 
same response. Traffic thus ceases to flow between 
serving channel element 245 and service circuit 612. 
Serving channel element 245 responds to receipt of 
the FS_ACK packet from service circuit 612 by caus- 
ing a HAN DOFFJN FORMATION message to be sent 10 
to ECP complex 134 to notify itof handoff completion, 
and ECP complex 134 updates its database. 

Once again, it will be noted that DCS controller 
261 of the serving DCS 201, remains wholly unin- 
volved in the procedure of FIG. 31 , and that ECP com- 15 
plex 138 is also uninvolved except for being notified 
of the completion of the procedure. Consequently, the 
call-handling capacity of controller 261 and ECP com- 
plex 134 is not adversely impacted by the semi-soft 
handoff procedure. 20 

FIG. 33 shows control signalling for a hard hand- 
off from one CDMA cell 202 to another. In CDMA, hard 
handoff does not necessarily involve a change in the 
mobile channel, but it does involve a change in the 
digital cellular switch 201 (see FIG. 2) which is han- 25 
dling the call. 

As for soft and semi-soft handoff, controller 241 
of ceil 202 that is handling the call --referred to as 
serving cell 202-- monitors PWR.INFO. supplied by 
mobile telephone 203 and uses it along with other sta- 30 
tus information to determine whether serving cell 202 
should continue to handle the call, or whether it should 
hand the call off to another cell 202 -referred to as 
new cell 202- that is connected to a different mobile 
telephone switch 201 than serving cell 202. If control- 35 
ler 241 of serving cell 202 determines to hand off the 
call, it sends a HARD_HANDOFF_REQUEST mes- 
sage to ECP complex 134. The message identifies 
the call, the proposed new cell 202, and the mobile 
channel that is being used for the call by serving cell 40 
202. 

ECP complex 134 responds to the message by 
determining which DCS 201 is connected to new cell 
202, and selecting a new speech coder module 220 
within that DCS 201 and as service circuit 612 of the 45 
new module 220 to handle the call. ECP complex 1 34 
then selects a trunk 206 connecting serving speech 
coder module 220 of serving DCS 201 with new 
speech coder module 220 of new DCS 201, and 
sends a SETUP message to controller 261 of serving so 
DCS 201 identifying the selected new speech coder 
module 220, service circuit 612, and trunk 206, and 
also identifying the trunk 106 of serving speech coder 
module 220 which carries the call. 

Controller 261 of serving DCS 201 receives the 55 
SETUP message and responds by causing controller 
231 of serving module 220 to seize the identified 
trunk 206, to outpulse thereon identification of the se- 



lected module 220 and service circuit 612, and to con- 
nect call-coding trunk 106 to trunk 206 in a conferenc- 
ing arrangement. This results in seizure of trunk 206 
at new module 220 and collection by new module's 
controller 231 of the outpulsed identification. Control- 
ler 261 of serving DCS 201 then sends a CONNACK 
message to ECP complex 134 to advise it of estab- 
lishment of the connection between serving and new 
modules 220, while controller 231 of new module 220 
sends the collected outpulsed information to control- 
ler 261 of new DCS 201, which sends an INCALL 
message conveying the collected outpulsed informa- 
tion to ECP complex 134 to advise it of the incoming 
call. 

ECP complex 134 associates the received CON- 
NACK and INCALL messages on the basis of their 
contents; the messages serve as confirmation to 
ECP complex 134 that TDM buses 130 of new and 
serving modules 220 are now interconnected through 
trunk 206. ECP complex 134 then sends a 
MSC_NEW_HANDOFF message to controller 241 of 
new cell 202. This message notifies new cell 202 that 
it has been selected to handle the call, and conveys 
to it the identification of the mobile channel that is pre- 
sently carrying the call. New cell controller 241 re- 
sponds by determining whether new cell 202 can han- 
dle the call, and if so, on which mobile channel. New 
cell controller 241 then sends a C HAN N E L_ACTI VA- 
TION_CONFIRMATION message conveying this in- 
formation back to ECP complex 134. Assuming that 
new cell 202 can handle the call, ECP complex 134 
sends to new cell controller 241 an MSC_FS_AS- 
SIGNMENT message conveying the DLCIs of the ser- 
vice circuit 61 2 of new module 220 which has been se- 
lected to handle the call. This message is the same as 
discussed previously in conjunction with FIG. 23, and 
elicits the same responses. New cell 202 returns an 
FS_CONFIRMATION message to ECP complex 134, 
and ECP complex 134 in turns sends an 
MSC_OLD_HANDOFF message to serving cell 202, 
advising them of completion of the connection be- 
tween new channel element 245 and new service cir- 
cuit 612, and the mobile channel on which new chan- 
nel element 245 operates. 

ECP complex 134 responds to the FS_CONFIR- 
MATION message by sending an ACCEPT message 
to controller 261 of new DCS 201. Controller 261 of 
new DCS 201 responds by causing controller 231 of . 
new module 220 to make connection between new 
service circuit 612 and trunk 206 connecting new 
module 220 to serving module 220, in the manner de- 
scribed previously for ACCEPT messages. This re- 
sults in the output of both new and serving service cir- 
cuits 612 being connected to the same time slot of 
TDM bus 1 30 of serving speech coder module 220, in 
a conference arrangement If both new and serving 
channel elements 245 are operating on the same mo- 
bile channel, this results in superimposition of dupli- 
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cate outputs on the same time slot, and thus has sub- 
stantially no effect on the time-slot contents. If the two 
channel elements 245 are not operating on the same 
mobile channel, this results in superimposition of real 
traffic and null traffic samples -speech or data, and 
silence- on the same time slot, and thus again has 
substantially no effect on the time-slot contents. Con- 
troller 261 of new DCS 201 then returns a CONNACK 
message to ECP complex 134 to advise it of comple- 
tion of the connection. Controller 231 of serving mod- 
ule 220 detects completion of the connection and no- 
tifies controller 261 of serving DCS 201, which re- 
turns an ANSWER message to ECP complex 134 to 
notify it thereof. 

Serving cell controller 241 responds to 
MSC_OLD_HANDOFF message that it receives from 
ECP complex 134 by checking the message contents 
to determine if new channel element 245 is operating 
on the same mobile channel as serving channel ele- 
ment 245. If not, serving cell controller 241 causes 
serving channel element 245 to transmit a signal to 
mobile telephone 203 commanding it to switch oper- 
ation from the mobile channel that it is now using to 
the mobile channel used by new channel element 
245, as shown in dashed lines in FIG. 33. When mo- 
bile telephone 203 does so, traffic flow is switched 
from serving cell 202 to new cell 202, as shown in 
dashed lines. 

Channel element 245 of new cell 207 responds to 
commencement of receipt of the call traffic by causing 
new cell controller 241 to send a HANDOFFVOICE 
CHANNEL_CONFIRMATION message to ECP com- 
plex 1 34. This message advises ECP complex 134 of 
success of the handoff. ECP complex 1 34 responds 
by sending an MSC_CHANNEL_DEACTIVATION 
message to serving cell 202 and a CLEAR message 
to controller 261 of serving DCS 201 to cause serving 
cell 202 and serving SPU 264 to drop out of handling 
of the call. 

Controller 241 of serving cell 202 forwards the 
MSC_CHANNEL_DE ACTIVATION message to serv- 
ing channel element 245, which responds by causing 
an FS_REMOVE packet to be relayed to serving ser- 
vice circuit 612. The packet is the same as described 
previously, and elicits the same response. When 
serving cell 202 has ceased to handle the call, its con- 
troller 241 sends an FS_CONFIRMATION message 
to ECP complex 134 to advise it thereof. 

Controller 261 of serving DCS 201 passes the re- 
ceived CLEAR message to controller 231 of serving 
module 220. Controller 231 responds by causing 
translation and maintenance processor 609 of speech 
processing unit 264 which contains serving service 
circuit 612 to disconnect the call (i.e, the time slot of 
TDM bus 130 which is carrying the call) from the con- 
centration highway 607 time slot that is assigned to 
that service circuit 612. However, because new ser- 
vice circuit 612 of new module 220 is now connected 



to trunk 106 that carries the call to and from TDM bus 
130 of serving module 220 via trunk 206, controller 
231 of serving module 220 does not release that trunk 
106 and TDM bus 130 time slot. Controller 261 of 

5 serving DCS 201 then sends a CLEAR_ACK mes- 
sage to ECP complex 134 to advise it that serving 
SPU 264 of serving module 220 has ceased to serve 
the call. Receipt of both the CLEAR_ACK and 
FS_CONFIRMATION messages indicates to ECP 

10 complex 134 that the handoff has been completed. 

FIGS. 34-35 show control signalling for a hard 
handoff from a CDMA radio 243 of a serving cell 202 
to a conventional analog radio 143 of a new cell 102 
5 or 202. FIG. 34 shows control signalling for the 

15 handoff between two cells connected to the same 
DCS 201, while FIG, 35 shows the handoff between 
two cells connected to different DCSs 201. 

Considering FIG. 34, a conventional mobile tel- 
ephony cell 102 may be equipped with a CDMA pilot 

20 channel. If it is, control communications proceed with 
a new cell 102 as they would with a new cell 202, and 
are shown in FIG. 33; if new cell 102 is not equipped 
with a CDMA pilot channel, the control communica- 
tions shown in FIG. 34 for new cell 102 instead also 

25 proceed with serving cell 202. In other words, if new 
cell 102 is not equipped with a CDMA pilot channel, 
conversion of the call to conventional mobile teleph- 
ony occurs on serving cell 202, and only then is the 
call handed off from serving cell 202 to new cell 102, 

30 in the conventional hard-handoff manner. 

As for handoff types discussed previously, con- 
troller 241 of serving cell 202 monitors PWR.INFO. 
supplied by mobile telephone 203 to determine 
whether or not to hand the call off to another cell. If 

35 controller 241 of serving cell 202 determines that it 
should handoff the call to a conventional radio 143 in 
a cell 202 or 102, and the new cell 202 or 102 is con- 
nected to the same mobile telephone switch 201 as 
serving cell 202, controller 241 sends an ANA- 

40 LOG_HANDOFF_REQUEST message to ECP com- 
plex 134. The message identifies the proposed new 
cell 1 02 or 202. ECP complex 1 34 responds by select- 
ing a trunk 109 of a switching module 120 or 220 to 
which new cell 102 or 202 is connected, and sending 

45 an MSC_NEW_HANDOFF message to controller 141 
or 241 of new cell 102 or 202. The message identifies 
the selected trunk 109 and queries if new cell 102 or 
202 can handle the call. Controller 141 or 241 of new 
cell 102 or 202 replies with a C H AN N E L_ACTI VA- 

50 TION_CONFIRMATION message to ECP complex 
134 identifying the conventional mobile channel on 
which it will handle the call, and also connects that 
mobile channel to the selected trunk 109. ECP com- 
plex 134 responds by selecting a trunk 109 that is 

55 connected to serving module 220, and sends a CON- 
NECT message to DCS controller 261 of serving DCS 
201 identifying new module 120 or 220 to which new 
cell 102 or 202 is connected, the selected trunk 109 

27 
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that is connected to new module 120 or 220, and the 
selected trunk 1 09 outgoing from serving speech cod- 
er module 220. 

DCS controller 261 of serving DCS 201 receives 
the CONNECT message and responds by causing 5 
controller 231 of serving module 220 to connect the 
call (the TDM bus 130 time slot) to the identified out- 
going trunk 109 in a conference arrangement, and 
causing TMS 121 to connect the two identified trunks 
109 to each other. Controller 261 of serving DCS 201 10 
then sends a CONNACK message to ECP complex 
134 to advise it of completion of the connection be- 
tween the serving and the new modules. 

ECP complex 134 responds by sending an 
MSC_OLD_HANDOFF message to controller 241 of 15 
serving cell 202 conveying the mobile channel on 
which the new cell 102 or 202 will handle the call. In 
response, controller 241 causes serving channel ele- 
ment 245 to transmit a signal to mobile telephone 203 
commanding it to switch to conventional mobile tel- 20 
ephony operation and to use the mobile channel that 
was specified in the MSC_NEW_HANDOFF mes- 
sage. 

When mobile telephone 203 does so and com- 
mences transmitting on the new mobile channel, new 25 
ceil 102 or 202 receives the transmissions and noti- 
fies ECP complex 134 via a HANDOFF_VOI- 
CE_CHANNEL_CONFIRMATION message. ECP 
complex 134 responds with an MS C_CH ANNE ^DE- 
ACTIVATION message to serving cell 202 and a 30 
CLEAR message to DCS controller 261 of serving 
DCS 201, to cause serving cell 202 and serving SPU 
264 to drop out of handling of the call. The messages 
are the same as discussed for CDMA-to-CDMA hard 
handoff, and elicit the same responses. As in that 35 
case, receipt of both the CLEAR_ACK and FS_CON- 
FIRMATION messages indicates to ECP complex 1 34 
that the handoff has been completed. 

Referring now to FIG. 35, the handoff to a new 
cell 102 or 202 connected to a different switch 101 or 40 
201 than serving cell 202 starts out the same way as 
shown in FIG. 34. But following a decision to hand off 
the call to a cell 102 served by a new DCS 101 or 201, 
controller 241 of serving cell 202 sends a ANA- 
LOG_HANDOFF_REQUEST message to ECP com- 45 
plex 134 to request the handoff. The message identi- 
fies the proposed new cell 102 or 202. ECP complex 
1 34 responds to this message by determining which 
switch 101 or 201 is connected to new cell 102 or 202, 
and selecting a new switching module 120 or 220 of so 
that switch 101 or 201 and a trunk 106 connected to 
that selected module 120 or 220 to handle the call. 
ECP complex 134 then selects an outgoing trunk 106 
connected to serving module 220 and sends a SET- 
UP message to DCS controller 261 of serving DCS 55 
201 identifying the selected new module 120 or 220 
and its connected trunk 106, the trunk 106 outgoing 
from serving speech coder module 220, and the trunk 



106 of serving speech coder module 220 which car- 
ries the call. 

The SETUP message is analogous to that descri- 
bed in conjunction with FIG. 33, and elicits like re- 
sponses. Hence, the handoff proceeds as described 
for FIG. 33. However, no SPU 264 will be involved in 
handling the call at new DCS 101 or 201, so instead 
of sending an FS_ASSIGN message to new cell 102 
or 202 as in FIG. 33, ECP complex 134 instead pro- 
ceeds directly to send an ACCEPT message to DCS 
controller 161 or 261 of new DCS 101 or 201. DCS 
controller 161 or 261 responds by causing controller 
131 of new module 120 or controller 251 of a cell in- 
terconnect module 209 to connect the selected trunk 
106 of new module 120 or 220 to the call (i.e., to the 
call's corresponding time slot or either TDM bus 130 
of module 120 or TDM bus 230 of CIM 209), thereby 
establishing a connection between that selected 
trunk 106 and new eel! 102 or 202. Akin to FIG. 33, 
this results in the output of both new cell 102 or 202 
and serving cell 202 being connected to the same 
time slot of TDM bus 130 of serving speech coder 
module 220. DCS controller 161 or 261 of new DCS 
101 or 201 then returns a CONNACK message to 
ECP complex 134 to advise it of completion of the 
connection, while controller 231 of serving module 
220 detects completion of the connection and notifies 
serving DCS controller 261, which responds by re- 
turning an ANSWER message to ECP complex 134. 

ECP complex 134 responds to receipt of the 
CONNACK message by sending an MSC_OLD_ 
HANDOFF message to controller 241 of serving cell 
202. The message is the same as discussed in con- 
junction with FIG. 34, and henceforth the handoff 
process the same as described for FIG. 34, until hand- 
off completion. 

Of course, it should be understood that various 
changes and modifications to the illustrative embodi- 
ment described above will be apparent to those skilled 
in the art For example, different packet transmission 
techniques, such as Asynchronous Transfer Mode 
(ATM) can be used. Or, the partitioning of functionality 
between the control entities of the cells, ECP com- 
plex, and the digital cellular switches can be changed. 
Also, modules within a digital cellular switch (both 
CIMs 209 and SCMs 220) may be interconnected by 
a center-stage switch instead of just directly by trunks. 
Furthermore, the system described above can be ap- 
plied to pseudo-synchronous wireless-access systems 
other than mobile telephony -for example, to personal 
communications networks (PCNs). Such changes and 
modifications can be made without departing from the 
spirit and the scope of the invention and without dimin- 
ishing its attendant advantages. It is therefore intended 
that all such changes and modifications be covered by 
the following claims. 
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Claims 

1 . A method of handling a call of a mobile wireless- 
call user terminal that is moving from a vicinity of 
a first service node to a vicinity of a second ser- 5 
vice node in a wireless-access telecommunica- 
tions system that includes the mobile wireless- 
call user terminal, a plurality of service nodes 
each for providing wireless-call services to wire- 
less-call user terminals in its vicinity, and at least 10 
one interface node connected to the service 
nodes and having a plurality of call processing 
units each for interfacing a wireless call that ex- 
tends between a user terminal and a service 
node to a telecommunications facility, the method 15 
comprising the steps of: 

communicating call traffic of the call be- 
tween the mobile user terminal and the first ser- 
vice node, and between one of the call processing 
units and a telecommunications facility; 20 

communicating the call traffic of the call 
between the first service node and the one call 
processing unit across a packet-switched call 
path set up for the call on a communication chan- 
nel between the first service node and the one 25 
call processing unit, using different fixed ad- 
dresses for different end points of the call path to 
route the call traffic across the channel; 

in response to detecting that the mobile 
user terminal is moving from the vicinity of the 30 
first service node to the vicinity of the second ser- 
vice node, sending notification thereof from the 
first service node to the second service node; 

in response to receiving the notification at 
the second service node, setting up a packet- 35 
switched call path for the call on a communication 
channel between the second service node and 
the one call processing unit by communicating 
across the communication channel between the 
second service node and the one call processing 40 
unit; 

communicating duplicate call traffic of the 
call between the mobile user terminal and the first 
and the second service nodes; 

communicating the duplicate call traffic of 45 
the call between the first and the second service 
nodes and the one call processing unit across the 
packet-switched call paths set up for the call on 
the communication channels between the first 
and the second service nodes and the one call so 
processing unit, using different fixed addresses 
for different end points of every call path to route 
the duplicate call traffic across the channels; and 

communicating a single copy of the dupli- 
cate call traffic of the call between the one call 55 
processing unit and the telecommunications fa- 
cility by duplicating the call traffic outgoing to the 
service nodes and discarding a duplicate of the 



call traffic incoming from the service nodes. 

2. The method of claim 1 wherein 

each step of communicating call traffic of 
the call between a service node and a call proc- 
essing unit comprises the step of: 

frame-relaying packets containing the call 
traffic between the service node and the call 
processing unit. 

3. The method of claim 1 wherein: 

each address of a call-path endpoint locat- 
ed at a service node identifies a wireless channel 
of the service node which corresponds to the call. 

4. The method of claim 3 wherein: 

each address of a call-path endpoint locat- 
ed at the one call processing unit identifies a dif- 
ferent logical port of the one call processing unit. 

5. The method of claim 1 wherein: 

each different address of a call-path en- 
dpoint comprises a different DLCI of LAPD pack- 
ets carrying the call traffic of the call. 

6. The method of claim 1 in a wireless-access tele- 
communications system that further includes a 
controller for connecting call processing units to 
calls, wherein: 

the recited steps all occur without involve- 
ment therein of the controller. 

7. The method of claim 1 in a wireless-access tele- 
communications system that further includes a 
system controller for coordinating operations of 
the service nodes and the interface node, where- 
in: 

the recited steps all occur without involve- 
ment therein of the controller. 

8. The method of claim 1 in a wireless-access tele- 
communications system that further includes an 
interface node controller for connecting call proc- 
essing units to calls and a supervisory controller 
for coordinating operations of the service nodes 
and the interface node, wherein: 

the recited steps all occur without involve- 
ment therein of the controllers. 

9. The method of claim 8 wherein 

the recited steps are preceded by the fur- 
ther steps of: 

detecting an origination of the call; 

in response to the detection of the origina- 
tion, notifying thereof the supervisory controller; 

in response to the notification, sending a 
first message from the supervisory controller to 
the first service node to establish a call path for 
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the call between the first service node and the 
one call processing unit; 

in response to the notification, sending a 
second message from the supervisory controller 
to the interface node controller to establish a call 
connection for the call between the one call proc- 
essing unit and the telecommunications facility; 

in response to receiving the second mes- 
sage at the interface node controller, establishing 
a call connection for the call between the one call 
processing unit and the telecommunications fa- 
cility by action of the interface node controller, 
and 

in response to receiving the first message 
at the first service node, setting up the packet- 
switched call path for the call on the communica- 
tion channel between the first service node and 
the one call processing unit by communicating 
across the communication channel between the 
first service node and the one call processing 
unit. 

10. The method of claims 1 further comprising the 
steps of: 

in response to detecting that the mobile 
user terminal is moving from a vicinity of both the 
first and the second service nodes to the vicinity 
of only an individual one of the first and the sec- 
ond service nodes, sending notification thereof 
from a detecting one of the first and the second 
service nodes to another one of the first and the 
second service nodes to indicate transfer of re- 
sponsibility for the call to solely the individual one 
of the first and the second service nodes; 

in response to the detecting, ceasing to 
communicate call traffic of the call from the other 
than the individual one of the first and the second 
service nodes; 

in response to the detecting, communicat- 
ing a notification thereof from the other than the 
individual one of the first and the second service 
nodes to the one call processing unit across the 
communication channel between the other than 
the individual one of the first and the second ser- 
vice nodes and the one call processing unit; and 

in response to receiving the notification at 
the one call processing unit, ceasing to commu- 
nicate call traffic of the call from the one call proc- 
essing unit to the other than the individual one of 
the first and the second service nodes. 

11. A method of handling a call of a mobile wireless- 
call user terminal that is moving from a vicinity of 
a first service node to a vicinity of a second ser- 
vice node in a wireless-access telecommunica- 
tions system that includes the mobile wireless- 
call user terminal, a plurality of service nodes 
each for providing wireless-call services to wire- 



less-call user terminals in its vicinity, and at least 
one interface node connected to the service 
nodes and having a plurality of call processing 
units each for interfacing a wireless call that ex- 

5 tends between a user terminal and a service 

node to a telecommunications facility, the method 
comprising the steps of: 

in response to receiving incoming call traf- 
fic of the call from the mobile user terminal at the 

10 first service node, sending first packets contain- 

ing the received incoming call traffic and each 
having a first address which identifies the call's 
corresponding one of the call processing units, 
from the first service node to the interface node; 

15 in response to receiving the first packets at 

the one call processing unit, sending the incom- 
ing call traffic contained in the first packets from 
the one call processing unit to a telecommunica- 
tions facility; 

20 in response to receiving outgoing call traf- 

fic of the call from the telecommunications facility 
at the one call processing unit, sending second 
packets containing the received outgoing call 
traffic and each having a second address differ- 

25 ent from the first address and which identifies the 

first service node, from the one call processing 
unit to the first service node; 

in response to receiving the second pack- 
ets at the first service node, sending the outgoing 

30 call traffic contained in the second packets from 

the first service node to the mobile user terminal; 

detecting that the mobile user terminal is 
moving from the vicinity of the first service node 
to the vicinity of the second service node; 

35 in response to the detecting, sending a 

message specifying a third address different 
from the first address and which also identifies 
the one call processing unit, from the first service 
node to the second service node; 

40 in response to receiving the message at 

the second service node, sending a third packet 
both (a) specifying a fourth address different from 
the second and the third addresses and which 
identifies the second service node and (b) having 

45 the third address, from the second service node 

to the interface node; 

in response to receiving incoming call traf- 
fic of the call from the mobile user terminal at the 
second service node subsequently to receiving 

so the message, sending fourth packets containing 
the received incoming call traffic and each having 
the third address, from the second service node 
to the interface node; 

in response to receiving the third packet at 

55 the one call processing unit, storing the fourth ad- 

dress for use in the call by the one call processing 
unit; 

in response to receiving outgoing call traf- 

30 
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f ic of the call from the telecommunications facility 
subsequently to receiving the third packet, send- 
ing the second packets from the one call process- 
ing unit to the first service node and sending fifth 
packets containing same received outgoing call 5 
traffic as the second packets and each having the 
fourth address, from the one call processing unit 
to the second service node; 

in response to receiving the fifth packets 
at the second service node, sending the outgoing 10 
call traffic contained in the fifth packets from the 
second service node to the mobile user terminal; 
and 

in response to receiving the first packets 
and the fourth packets both containing same re- 15 
ceived incoming call traffic at the one call proc- 
essing unit subsequently to receiving the third 
packet, selecting the incoming call traffic con- 
tained by one of the received first and fourth 
packets that contain the same traffic, and send- 20 
ing only the selected incoming call traffic to the 
telecommunications facility. 

12. In a wireless-access telecommunications system 

that includes at least one mobile wireless-call 25 
user terminal, a plurality of service nodes each 
for providing wireless-call services to wireless- 
call user terminals in its vicinity, and at least one 
interface node connected to the service nodes 
and having a plurality of call processing units 30 
each for interfacing a wireless call that extends 
between a user terminal and a service node to a 
telecommunications facility, the improvement 
comprising: 

first means for communicating call traffic 35 
of the call between a mobile user terminal that is 
in the vicinity of the first service node and the first 
service node; 

second means cooperative with the first 
means for communicating the call traffic of the 40 
call between the first service node and the call's 
associated one of the call processing units across 
a packet-switched call path set up for the call on 
a communication channel between the first ser- 
vice node and the one of the call processing units. 45 
by using different fixed addresses for different 
endpoints of the call path to route the call traffic 
across the channel; 

third means cooperative with the second 
means for communicating the call traffic of the so 
call between the one call processing unit and a 
telecommunications facility; 

fourth means in the first service node re- 
sponsive to detecting that the mobile user termi- 
nal is moving from the vicinity of the first service 55 
node to the vicinity of the second service node, 
for sending notification thereof to the second ser- 
vice node; 



fifth means in the second service node re- 
sponsive to receiving the notification, for setting 
up a packet-switched call path for the call on a 
communication channel between the second ser- 
vice node and the one call processing unit by 
communicating across the communication chan- 
nel with the one call processing unit; 

sixth means for communicating the call 
traffic of the call between the mobile user termi- 
nal moving into the vicinity of the second service 
node and the second service node, so that dupli- 
cate copies of the call traffic are communicated 
between the mobile user terminal when it is mov- 
ing from the vicinity of the first service node to the 
vicinity of the second service node and the first 
and the second service nodes; 

seventh means cooperative with the sixth 
means for communicating the call traffic of the 
call between the second service node and the 
one call processing unit across the packet- 
switched call path set up for the call on the com- 
munication channel between the second service 
node and the one call processing unit, by using 
different fixed addresses for different endpoints 
of every call path to route the call traffic across 
the channel, so that duplicate copies of the call 
traffic are communicated between the one call 
processing unit and the first and the second ser- 
vice nodes when the mobile user terminal is mov- 
ing from the vicinity of the first service node to the 
vicinity of the second service node; and 

eighth means in the one call processing 
unit cooperative with the second, the need, and 
the seventh means, for duplicating the call traffic 
communicated from the telecommunications fa- 
cility and outgoing to the service nodes and dis- 
carding a duplicate of the call traffic incoming 
from the service nodes and communicated to the 
telecommunications facility, so that only a single 
copy of the call traffic is communicated between 
the one call processing unit and the telecommu- 
nications facility when the mobile user terminal is 
moving from the vicinity of the first service node 
to the vicinity of the second service node. 

1 3. The improvement of claim 1 2 wherein the second 
and the seventh means each include: 

means for frame-relaying packets contain- 
ing the call traffic between a service node and a 
call processing unit 

14. The improvement of claim 12 wherein: 

each address of a call path endpoint locat- 
ed at a service node identifies a wireless channel 
of the service node which corresponds to the call. 

15. The improvement of claim 12 wherein: 

each address of a call path endpoint locat- 
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ed at the one call processing unit identifies a dif- 
ferent logical port of the one call processing unit. 

16. The improvement of claim 12 wherein: 

each different address of a call path en- 5 
dpoint comprises a different DLCI of LAPD pack- 
ets carrying the call traffic of the call, 

17. The improvement of claim 12 in a wireless-ac- 
cess telecommunications system that further in- 10 
eludes a controller for connecting call processing 
units to calls, wherein: 

the recited means all perform their func- 
tions without involvement therein of the controller 
while the mobile user terminal is moving from the 15 
vicinity of the first service node to the vicinity of 
the second service node. 

18. The improvement of claim 12 in a wireless-ac- 
cess telecommunications system that further in- 20 
eludes a system controller for coordinating oper- 
ations of the service nodes and the interface 
node, wherein: 

the recited means all perform their func- 
tions without involvement therein of the controller 25 
while the mobile user terminal is moving from the 
vicinity of the first service node to the vicinity of 
the second service node. 

19. The improvement of claim 12 in a wireless-ac- 30 
cess telecommunications system that further in- 
cludes an interface node controllerfor connecting 

call processing units to calls and a supervisory 
controller for coordinating operations of the ser- 
vice nodes and the interface node, wherein: 35 

the recited means all perform their func- 
tions without involvement therein of the control- 
lers while the mobile user terminal is moving from 
the vicinity of the first service node to the vicinity 
of the second service node. 40 

20. The improvement of claim 12 further comprising: 

ninth means responsive to detection that 
the mobile user terminal is moving from a vicinity 
of both the first and the second service nodes to 45 
the vicinity of only the second service node, for 
sending notification thereof from a detecting one 
of the first and the second service nodes to an- 
other one of the first and the second service 
nodes to indicate transfer of responsibility for the 50 
call to solely the second service node; wherein 

the first means are responsive to the de- 
tection by ceasing to communicate call traffic of 
the call between the first service node and the 
mobile user terminal; 55 

the second means are responsive to the 
detection by ceasing to communicate call traffic 
of the call between the first service node and the 



one call processing unit and by communicating a 
notification thereof to the one call processing unit 
across the communication channel between the 
first service node and the one call processing 
unit; and 

the eighth means are responsive to receipt 
of the notification from the second means by 
ceasing to duplicate and to discard the call traffic. 

21. The improvement of claim 12 further comprising: 

ninth means responsive to detection that 
the mobile user terminal is returning from a vicin- 
ity of both the first and the second service nodes 
to the vicinity of only the first service node, for 
sending notification thereof from a detecting one 
of the first and the second service nodes to an- 
other one of the first and the second service 
nodes to indicate transfer of responsibility for the 
call to solely the first service node; wherein 

the sixth means are responsive to the de- 
tection by ceasing to communicate call traffic of 
the call between the second service node and the 
mobile user terminal; 

the seventh means are responsive to the 
detection by ceasing to communicate call traffic 
of the call between the second service node and 
the one call processing unit and by communicat- 
ing a notification thereof to the one call process- 
ing unit across the communication channel be- 
tween the second service node and the one call 
processing unit; and 

the eighth means are responsive to receipt 
of the notification from the seventh means by 
ceasing to duplicate and to discard the call traffic. 

22. I n a wireless- access telecommunications system 
that includes at least one mobile wireless-call 
user terminal, a plurality of service nodes each 
for providing wireless-call services to wireless- 
call user terminals in its vicinity, and at last one in- 
terface node connected to the service nodes and 
having a plurality of call processing units each for 
interfacing a wireless call that extends between a 
user terminal and a service node to a telecommu- 
nications facility, the improvement comprising: 

first means in the first service node, re- 
sponsive to receiving incoming call traffic of the 
call from a mobile user terminal that is in the vi- 
cinity of the first service node, for sending to the 
interface node first packets containing the re- 
ceived incoming call traffic and each having a 
first address which identifies the call's corre- 
sponding one of the call processing units; 

second means in the one call processing 
unit responsive to receiving the first packets, for 
sending the incoming call traffic contained in the 
first packets to a telecommunications facility; 

third means in the one call processing unit, 
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responsive to receiving outgoing call traffic of the 
call from the telecommunications facility, for 
sending to the first service node second packets 
containing the received outgoing call traffic and 
each having a second address different from the 5 
first address and which identifies the first service 
node; 

fourth means in the first service node, re- 
sponsive to receiving the second packets, for 
sending the outgoing call traffic contained in the w 
second packets to the mobile user terminal; 

fifth means in the first service node, re- 
sponsive to a detection that the mobile user ter- 
minal is moving from the vicinity of the first ser- 
vice node to the vicinity of the second service is 
node, for sensing to the second service node a 
message specifying a third address different 
from the first address and which also identifies 
the one call processing unit; 

sixth means in the second service node, 20 
responsive to receiving the message, for sending 
to the interface node a third packet both (a) spec- 
ifying a fourth address different from the second 
and the third addresses and which identifies the 
second service node and (b) having the third ad- 25 
dress; 

seventh means in the second service 
node, responsive to receiving incoming call traffic 
of the call from the mobile user terminal subse- 
quently to the second service node receiving the 30 
message, for sending to the interface node fourth 
packets containing the received incoming call 
traffic and each having the third address; 

eighth means in the one call processing 
unit, responsive to receiving the third packet, for 35 
storing the fourth address for use in the call by 
the one call processing unit; 

the third means further responsive to re- 
ceiving outgoing call traffic of the call from the tel- 
ecommunications facility subsequently to the one 40 
call processing unit receiving the third packet, for 
sending the second packets to the first service 
node and also sending to the second service 
node fifth packets containing same received out- 
going call traffic as the second packets and each 45 
having the fourth address; 

ninth means in the second service node, 
responsive to receiving the fifth packets, for 
sending the outgoing call traffic contained in the 
fifth packets to the mobile user terminal; and so 

the second means further responsive to 
receiving both the first packets and the fourth 
packets both containing same received incoming 
call traffic subsequently to the one call process- 
ing unit receiving the third packet, for selecting 55 
the incoming call traffic contained by one of the 
received first and fourth packets that contain the 
same traffic and sending only the selected in- 



coming call traffic to the telecommunications fa- 
cility. 
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